By: Tom Sydney Kerckhove <syd@cs-syd.eu>
Report a top-level binding in a test file beside spec A helper in a test file is code with no test over it, in the one place nothing else can import. Every test that calls it reads as whatever the helper does today, so the helper drifts and takes the meaning of those tests with it, and the failure lands on them rather than on it. Which fix applies is the helper's to say, and the rule names all three. One that hides what a test asserts is duplicated into each test that uses it. One that holds real logic becomes a function in the library, where a test can reach it. One that builds a Spec is worth keeping whole and goes in a TestUtils module the test files import: that is what makes a suite where adding a case adds a resource and no test code, and it belongs somewhere it can be named and read on its own. A let-binding is none of this rule's business, since a binding inside spec is read with the test that uses it. Sixty-one findings against this repository, every one of them in its own test suite and every one of them fixed rather than suppressed: the helpers that hid what a test asserts are now let-bindings in the spec that uses them, and the ones that build a Spec are functions in Hopinion.TestUtils. RuleSpec is the whole of the second kind, and is now four meta-properties and one mapM_.
Total
1m41s
Created Started Finished
| Time to Start | Worker time | Duration | Time to finish | Idle | |
|---|---|---|---|---|---|
| Config | 0s | 0s | 0s | 1s | 0s |
| Eval | 1s | 10s | 10s | 12s | 0s |
| Build | 7s | 0s | 1m34s | 1m41s | 1m29s |
| Suite | 0s | 11s | 1m41s | 1m41s | 1m29s |