Testing has a bad rap. The thought of writing unit tests to exercise code with the goal of 100% code coverage can be overwhelming for many projects. The number of man-hours to set up tests, create mocks when needed, test boundary conditions, contrive odd ball test cases can take some steam out of the project. If this is the definition of test, then yes, writing these types of tests can be tedious and feel meaningless.

I am a proponent of writing tests with a narrow focus. The tests I describe here show the completion of a story or the resolution of a bug. With this narrowness in mind, the task is much less daunting. My goal now is not about code coverage, but more about quality code. With this test, I want to be able to demonstrate to myself (and to whoever is reviewing my changes), that I have successfully resolved my task.

In this blog I will talk about my suggestions for writing meaningful tests in the context of a code review.