• by rstuart4133 on 3/2/2017, 3:32:56 AM

    I don't agree with him.

    Everyone knows when you are forced to write tests you code differently because you have to make the lines tested visible to the testing code. In legacy code without tests no one bothered to do this, which is why adding tests to legacy code is near impossible.

    If 100% test coverage isn't forced you end up with lines that aren't visible to unit tests without re-factoring. If a bug is found in those lines and you want to add a test to demonstrate the bug has been fixed, you can't just make a minimal change - you have to re-factor the bloody thing, increasing the odds you will introduce another bug.

    The bottom line is ensuring you have 100% test coverage (or even better 100% branch coverage) brings it's own rewards because of the discipline it enforces in code structure, and that is true even if those test lines don't do much in the way of useful testing.

    So for me his argument only works you have 100% coverage. Thereafter, yeah, each test has to earn it keep.

  • by taylodl on 2/28/2017, 9:36:33 PM

    I addressed a lot of these concerns in my blog post on Maintenance Driven Development. https://taylodl.wordpress.com/2012/07/21/maintenance-driven-...

    Yes, fine-grained tests are problematic and as such one tends to desire to minimize the creation of such tests as much as possible. But when bugs are discovered then it may be necessary to create fine-grained tests in that affected area. Essentially what you're doing is the most extensive testing in the area of your code giving you the most problems. If you notice a particular area of your code requiring a lot of extensive unit tests then perhaps it's time to consider refactoring that code.

  • by Ace17 on 3/1/2017, 6:22:50 AM

    Each unit test not ending with an assertion is essentially a hack to locally silence your coverage tool, without actually improving the quality of your test suite.

    I call these tests "crash-tests", as a crash is nearly the only thing that they can detect. Crash-tests are indeed what you get if your devs are aiming at a high-coverage number without understanding the rationale behind code coverage.