4 ms·
I always see unit tests as a snapshot of dynamic behavior by 'recording' the tested logic. I make sure I'm aware of any logic changes since that change could ev
by donjoe 8y ago
I always see unit tests as a snapshot of dynamic behavior by 'recording' the tested logic. I make sure I'm aware of any logic changes since that change could eventually break the desired result.
Whenever I'm vetting in-/output values to a given set of parameters, I do move from white box (unit tests) to grey box testing.
When I'm done with grey/white box tests, I do make sure integration works as expected.
Why all the hustle of moving through 'the onion'? I wanna make sure to detect misbehaving/unexpected logic as quickly as possible. Searching for malfunction detected while running integration tests takes way more time than already catching them at the onion's most inner layer (unit tests).
- usrusr 8y agoWhen the result of the function under test is nontrivial, but JSONable, I make it literally a recording: set your favorite JSON tool to pretty print and compare the output to the expectation in a string literal or file. Any change will be easy to inspect, diff viewers are great. The expected counterpart may or may not start out to be manually authored. After changes, it's usually much easier to inspect the diff and copy the approved version or edit a copy of partially correct output.
- donjoe 8y agoYes, I do exactly the same to make sure the output stays the same. Snapshotting is awesome (for go, cupaloy works quite well [1] - jest for react is great) but does not give me the chance to 'record' the underlying logic dynamics. That's why I think unit tests are still an important tool at hand. [1] https://github.com/bradleyjkemp/cupaloy https://github.com/bradleyjkemp/cupaloy