Testing and Code Coverage

This past week, I have been learning about testing and code coverage, which is a measure of how thoroughly a test suite actually tests the code in a program. Using the test coverage tool Emma on the Stack Project that I worked on last week, I found that the coverage was around 80%. This means that the project's test suite only executes about 80% of the code in the program. In particular, the Stack.toString, ClearStack.getTop, and ClearStack.isEmpty methods are never tested by the test cases.

Toward 100% Code Coverage

Writing additional test cases to exercise these untested methods was quite straightforward. For ClearStack.getTop, I pushed and popped some objects onto a stack and checked that the method returned the correct object in each case. I also made sure to test that the method throws an EmptyStackException when called from an empty stack. For ClearStack.isEmpty, I checked that the method returned true for an empty stack and false for a non-empty stack. To test Stack.toString, I pushed various objects onto a stack and checked that the method returned a string representation of the stack. Actually, I did not know what to check for here, since I did not know what the returned string was supposed to look like, so I wrote a JUnit test to find out the format of the string. I was then able to write a different test to check that the method returned an appropriate string in that same format. I admit that this is circular logic, and probably is not the best testing practice.

My Stack Project with 100% code coverage is available here

Is 100% Code Coverage Useful?

Emma identified areas in the source code that weren't being tested, and once given these pointers, I made a good faith attempt to write tests that would thoroughly exercise these areas. Were these additional test cases useful? The Stack.toString method essentially uses the Java Collections API to return a string representation of the calling object, so I was confident that it would work properly. The ClearStack.getTop and ClearStack.isEmpty methods are so simple that it was clear from inspection that they would work correctly. I suppose it is nice to be reassured that the methods really work, but the additional tests did not reveal anything unusual or unexpected, and ultimately did not improve the quality of the system. The moral here is that increasing your code coverage to 100% does not necessarily contribute anything to your project, and is not necessarily a worthwhile goal. However, code coverage tools are still useful for pointing out areas of code that are under-tested and could potentially contain bugs.