Naming convention for methods with JUnit

Hello

Could you share your experience how do you (your company) test code?
We are using JUnit 4, and we have naming convention for all test methods.

after annotation @Test, we give each method name
test<OriginalMethodName>

testMakeSearch()
testReset()
and so on

but sometimes we have to make more then one test case for one method.

For example: we want to test makeSearch(...) with different parameters.

We have two possible solutions:
1. put all checks in one method, like:
public testMakeSearch() {
case1
case2
...
}

2. make one test method for each case

Variant 1 is not too good, as we will not see what cases are ok - we will see fail after first fail.

Variant 2 is better, but I don't know which naming convention to use...

testMakeSearch_case1()
testMakeSearch_case2()

but as I know "_" is not recommended in names (but not resticted)

how do you resolve this?

thanks

Hmmm, I often name mine after the input or expected result. testTooLarge() testTooSmall() testWithPunctuation(). Can't say I have a convention.

Naming with case description is good for small classes. On fail it is 100% where the problem is.
But it will be hard to get code coverage...

Frankly, I think that convention is far from optimal.

First, the test-prefix is redundant. The annotation already communicates that it is a test method. So why repeat that in the method name?

Second, and more importantly, in my opinion you shouldn't think about it as testing methods at all, you should think about it as testing behavior of the class. Consequently, I like my test method names to communicate the expected behavior.

So names of test methods that I would be likely to use could include

searchOnEmptyCollectionFindsNoResult
searchByNameFindsCorrectEntries
searchAfterResetFindsFirstHitAgain (or resetClearsCriteria or whatever reset is actually supposed to do)

etc. pp.

Hi Andrew,

You can easily pass parameters to your test methods with TestNG's Data Providers, which I described in this thread:

http://www.coderanch.com/t/96288/Testing/most-important-feature-TestNG

Once you can pass parameters to your test methods, nothing stops you from overloading the same method name several times with different signatures...

--
Cedric

I tend to describe the behavior I'm verifying in the name of my tests, e.g. "fooShouldBarWhenWhizGoesBang()" or "fooTellsAllBarsToCloseTooEarly()".

Sometimes I also do something like this:

public class TestClusterOfThreeNodes {
 
    private Cluster cluster;
    private FakeNode node1;
    private FakeNode node2;
    private FakeNode node3;
 
    @Before
    public void setUp() {
        node1 = new FakeNode();
        node2 = new FakeNode();
        node2 = new FakeNode();
        cluster = new Cluster();
        cluster.attach(node1);
        cluster.attach(node2);
        cluster.attach(node3);
    }
 
    @Test
    public void loadBalancesRequestsBetweenAllThreeNodesUsingRoundRobin() {
        simulateRequestsToCluster(3);
        assertEquals(1, node1.numberOfRequestsServed());
        assertEquals(1, node2.numberOfRequestsServed());
        assertEquals(1, node3.numberOfRequestsServed());
    }
 
    @Test
    public void startsLoadBalancingRequestsWithLiveNodesWhenOneGoesDown() {
        node2.stopResponding();
        simulateRequestsToCluster(4);
        assertEquals(2, node1.numberOfRequestsServed());
        assertEquals(2, node3.numberOfRequestsServed());
    }
}

That is, I name the test class according to the fixture set up with the @Before method. For example, above we have a cluster of three nodes so I name the test class like that - (Test)ClusterOfThreeNodes. The test methods, on the other hand, read out as statements about the system's behavior in the state described by the fixture (and the class name). For example, "loadBalancesBetweenAllThreeNodesUsingRoundRobin()".

So when I look at a test class, I mentally parse the class and method names as "ClusterOfThreeNodes.loadBalancesBetweenAllThreeNodesUsingRoundRobin".