Writing standards for unit testing

Question

I plan to introduce a set of standards for writing unit tests into my team. But what to include?

These two posts (Unit test naming best practices and Best practices for

Answer 1

Users of full-featured IDE's will find that "some of them" have quite detailed support for creating tests in a specific pattern. Given this class:

public class MyService {
    public String method1(){
        return "";
    }

    public void method2(){

    }

    public void method3HasAlongName(){

    }
}

When I press ctrl-shift-T in intellij IDEA I get this test class after answering 1 dialog box:

public class MyServiceTest {
    @Test
    public void testMethod1() {
        // Add your code here
    }

    @Test
    public void testMethod2() {
        // Add your code here
    }

    @Test
    public void testMethod3HasAlongName() {
        // Add your code here
    }
}

So you may want to take a close look at tool support before writing your standards.

Answer 2

I follow the BDD style of TDD. See: http://blog.daveastels.com/files/BDD_Intro.pdf http://dannorth.net/introducing-bdd http://behaviour-driven.org/Introduction

In short this means that

• The tests are not thought as "tests", but as specifications of the system's behaviour (hereafter called "specs"). The intention of the specs is not to verify that the system works under every circumstance. Their intention is to specify the behaviour and to drive the design of the system.

• The spec method names are written as full English sentences. For example the specs for a ball could include "the ball is round" and "when the ball hits a floor then it bounces".

• There is no forced 1:1 relation between the production classes and the spec classes (and generating a test method for every production method would be insane). Instead there is a 1:1 relation between the behaviour of the system and the specs.

Some time ago I wrote TDD tutorial (where you begin writing a Tetris game using the provided tests) which shows this style of writing tests as specs. You can download it from http://www.orfjackal.net/tdd-tutorial/tdd-tutorial_2008-09-04.zip The instructions about how to do TDD/BDD are still missing from that tutorial, but the example code is ready, so you can see how the tests are organized and write code that passes them.

You will notice that in this tutorial the production classes are named such as Board, Block, Piece and Tetrominoe which are centered around the concepts of a Tetris game. But the test classes are centered around the behaviour of the Tetris game: FallingBlocksTest, RotatingPiecesOfBlocksTest, RotatingTetrominoesTest, FallingPiecesTest, MovingAFallingPieceTest, RotatingAFallingPieceTest etc.

Answer 3

1. Try to use as few assert statements per test method as possible. This makes sure that the purpose of the test is well-defined.
2. I know this will be controversial, but don't test the compiler - time spent testing Java Bean accessors and mutators is better spent writing other tests.
3. Try, where possible, to use TDD instead of writing your tests after your code.

Answer 4

If you are using tools from the family of Junit (OCunit, SHunit, ...), names of tests already follow some rules.

For my tests, I use custom doxygen tags in order to gather their documentation in a specific page.