Assert coverage — the next step after code coverage?

Test-driven development with code coverage has been the hallmark of excellent software development for decades. However, it is possible to achieve high code coverage without adhering to strict test-driven development (TDD) and even without having proper asserts in place. In principle, you can achieve a near-perfect code coverage only using assert(true), i.e., tests that do not require anything from the code except being able to compile and run. You may be skeptical, but I actually had a former colleague who “skillfully” achieved good code coverage on his work with this approach… Notice the word former, i.e., not a path I would recommend following. Despite this extreme case, it is often easy to build a false sense of security, or high code coverage, with rather poorly written test asserts.

Photo by Chris Ried on Unsplash

To my knowledge, no static code analysis tool will analyze your unit tests and asserts to assess how well they cover the code. Please add a comment if you are aware of such a tool.

Property coverage — the second-best thing?

While we wait for the assert coverage tool, I will propose to use a technique I call property coverage. I write most code in C# using the SOLID principle, TDD, and sandwich testing. Consequently, I have clear separation of code into data-holding classes and…