Kent Beck on Software Engineering Radio, Episode 167: The History of JUnit and the Future of Testing with Kent BeckI want my tests to read like a story.
Every unit test tells a story about the unit under test (UUT). It shows how it is intended to be used and the result of the test run shows, if a particular feature is broken, not yet implemented or working.
An important part of the documentation is the name of the test method itself. The name should express the intention, the feature, not some technical details. So calling a test method
testsAddingElementsWorks
does not tell much about the unit being tested. If our unit is a set implementation, the following test method names will provide a much clearer view on the features of this unit (e.g. if the reader does not know what a set is):
Reading these method names allows the reader to get a picture of the unit being tested.
Unfortunately the test method names in their camel case form are harder to read than the features text on the product's cardboard box. Also being interested in the names only, the code itself is a form of distraction. Although the outline of an editor is provided by any IDE, a report that contains only the names in an easy to read sentence form is quite handy. TestDox by Chris Stevenson is to our knowledge the first tool (in form of a Maven 1 plugin) that allows to make readable sentences from the test method names. The smartics testdoc project also makes this translation, but also connect to the test source code (created by the maven-jxr-plugin) to read the whole story of the test.
The name of the test does not make the complete story. So it is important to have a link to the test code to really get the whole picture.
The report will also link to other reports, like the Javadoc or the test report. Each link and each column of the table can be configured to be not shown, so that the report shows only the information that is relevant to the intended audience.
As there are tests on different levels, like unit tests, performance tests, or acceptance tests, the stories being told are also on different levels and target different audiences. To characterize a test use the JUnit @Category annotation.
The goal of using test stories is to provide valuable and executable documentation on the components of your projects. The reports allow to control the quality of the test code, especially the naming of the test methods.
The reports also make it easy to find the test code for a particular tested class. While there is often a 1:1 relation between the tested class and the test case class that tests it, we often find us writing test cases in different test case classes. This has sometimes semantical reasons to group tests with a certain aspect, but often also technical reasons, when tests require a different test setup or fixture.
So what do you have to do, to try this out for your projects?