,
6 tweets,
1 min read
Read on Twitter
Fast-running developer tests (or "unit tests") are essential to making code changes easy and safe. When devs tell you to ditch them in favour of slower-running high-level (API, customer, system etc) tests... well, all can say is I've seen that go badly wrong many times. (1/)
The typical justification given for ditching unit tests is that they make refactoring harder. This tends to only be true when we forget to refactor the unit test code, or when the imlementation design has serious dependency issues, and/or when we over-rely on mock objects (2/)
It's also often a symptom of design-driven testing, where devs feel they have to write a unit test for every feature of every class/module. You don't. "Unit" doesn't have to mean a single method on a single class with all the dependencies mocked or stubbed. (3/)
Write tests for interesting behaviour. Don't worry if each test ends up touching multiple methods/functions in multiple classes/modules. And try to minimise what your tests know about the code they're testing. Lack of encapsulation will hurt your test code. (4/)
If renaming, say, an interface breaks a whole bunch of tests, that's telling you something. (5/5)
By which I mean "executing", not necessarily directy referencing. If the details are hiidden behind nce, simple interfaces, your tests don't need to know a lot.
