Code coverage and meaningful unit tests

It always worries me if I spot something like the following in a unit test during a code review:

testSomething {
  helper.foo()
}

Whilst this exercises a path through the code base (which helps to appease Cobertura), ensures that no exceptions are thrown and there are no ‘typo’ errors in the Groovy code (e.g. wrong property) it isn’t a valid test. A valid ‘black-box’ test should apply known input and compare the output to the expected output.

Ok, so this problem doesn’t just apply to unit tests – it can happen with automated integration tests or functional tests too. However for the unit test you should use mock collaborators to allow the test to just exercise the ‘unit under test’.

The real underlying problem is that the developer isn’t follow the Test Driven Development process. They’ve taken on board that the “code must have 80% automated unit test coverage” but are going about it in the wrong way. So it’s time for some re-education on why the tests must check the output and why writing the test first helps them think about how the class needs to work. Alternatively go for a behaviour driven approach and make the requirements executable!

Now I wonder if I can quickly write a CodeNarc ruleset to flag any test methods that don’t contain assertions…

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s