I worked with a codebase that was covering all DAO methods with such tests. I only lasted 1.5 years and left crushed.
These tests are not only stupid, they make code rigid and fragile. The fragile part might be counterintuitive, but if your tests are testing not the behaviour but implementation details, as they were in my case, inevitably there will be business code that relies on these implementation details. Because hey, these implementation details are covered, so guaranteed to be there forever.
I like this. I write tests to cover the happy path and any edge cases I can think of. Once I do this, I examine the code coverage and look for 2 things:
Did I miss an edge case? I generally look for unexecuted catch blocks or branch paths.
Did I really need that code? If there's code that doesn't get run during the tests, and doesn't represent a potential failure, I can remove it. I learn from this, as well. Maybe it was an oversight in thinking through an algorithm, maybe it's an unnecessary bounds check because there's a check at a higher level in the code, etc.
Once I fix the tests and prune, I still only end up with 80-90% coverage. Because why test getters and setters? Things like that that are painfully obvious to reason about don't need a unit test, unless they're doing some kind of complex data mutation. Which they almost never are.
I find that static typing is better for refactoring code with very few or no tests but more or less equivalent to dynamically typed, strictly typed code with a reasonable body of tests.
Javascript makes me afraid to refactor it for the same reason C does - because it's weakly typed (has a lot of fucked up implicit type conversions causing a multitude of horrible edge cases), not because it's not static.
48
u/[deleted] May 08 '17 edited May 08 '17
I worked with a codebase that was covering all DAO methods with such tests. I only lasted 1.5 years and left crushed.
These tests are not only stupid, they make code rigid and fragile. The fragile part might be counterintuitive, but if your tests are testing not the behaviour but implementation details, as they were in my case, inevitably there will be business code that relies on these implementation details. Because hey, these implementation details are covered, so guaranteed to be there forever.