Over a million developers have joined DZone.

Unit Test Naming Conventions

· Java Zone

Check out this 8-step guide to see how you can increase your productivity by skipping slow application redeploys and by implementing application profiling, as you code! Brought to you in partnership with ZeroTurnaround.

There are a certain number of naming conventions used for unit tests. In the beginning, with JUnit 3, to define a test it was mandatory that the class name was named like MyClassTest, be extending from TestCase and all the test method names were starting with 'test' as in 'testMyMethod()'. I think that this is a good example of convention over configuration.
With JUnit 4 (or TestNG) this is longer mandatory and it leaves the developer free to define his own naming convention. But then you "configure" the method as a test using the @Test annotation.

There is a naming convention defined by BDD which says that the test class and the test methods should describe the behavior you want to verify.

Examples:

having the test methods starting with should

public class WhenWindowControlCloseWindow {

@Test
public void shouldCloseWindows() {
//...
}
}

Or as in this example (from wikipedia), which also uses comments to describe the test: given/when/then:

public class WindowControlBehavior {
@Test
public void shouldCloseWindows() {

// Given
WindowControl control = new WindowControl("My AFrame");
AFrame frame = new AFrame();

// When
control.closeWindow();

// Then
ensureThat(!frame.isShowing());
}
}

or another convention I saw:

public class WindowControlShould {
@Test
public void closeWindows() {
//...
}
}

The problem here is that you have 3 elements in a test: the 'entity' subject of the test (usually a class name), the condition ('when calling some method with some specific parameters), and the expected result, that as we saw in BDD with the "shouldDoSomething" method name. So the problem is that with the class name and the method name we only have two elements to describe our test.
To express the 3rd 'entity' of the phrase, I tried to use inner classes to define tests like this:

public class WindowControl
public static class WhenCloseWindow {
@Test
public void shouldCloseWindows() {
//...
}
}
}

But it isn't supported by JUnit4.

I thought that packages might help, like specifying them as

package com.mycompany.blah.blah.windowcontrol;
public static class WhenCloseWindow {
@Test
public void shouldCloseWindows() {
//...
}
}

But in this way you lose the possibility to invoke default and package accessible methods, which is a thing that I quite like in my tests.

My feeling now is that first the test methods were identified by a naming convention. Then with the annotation, the convention has been left to the developer to choose, or even the choice to not have a convention at all. The annotation, for me is more close to a configuration thing, which is replacing a convention; a sort of counter-tendency in the trend of convention over configuration paradigm. So if we start to call our test method shouldSomething() are we not going back to the old convention testSomething() ?
Well I liked the conventions used in JUnit 3 and I don't really see big improvements in using the annotations, or being free from extending the TestCase class, which was providing the assert* methods: with JUnit4 we have to static import those methods from the class Assert; I don't see it as an improvement.
My taste is that, if we can't easily find a descriptive naming convention for what we are testing, relying on some comments could be the best thing. The example above - the one coming from wikipedia - is in fact using a naming convention plus some comments in the code. I think that using a comment on top of the method would have served better the purpose of describing the test.

Finally, some continuous integration tools are able to format the test names (class + method) to show a sentence describing the test nicely in natural English language.
That is cool, but since we have the @Test annotation already there to configure the test, why not having a descriptive attribute that can be used from reporting tools, like:

@Test(description="when WindowController.closeWindow() is invoked the window is closed")
public void testCloseWindow() {
//...
}

Or, since I criticized the @Test annotation, a short java comment would have sorted the same purpose for the tools willing to describe the test with a plain English description.

Since there isn't around a really good naming convention for tests, since I don't see real improvements using annotations and static imports... I think that JUnit 3 was doing right.

What do you think?

From http://en.newinstance.it/2011/01/28/unit-test-naming-conventions/

The Java Zone is brought to you in partnership with ZeroTurnaround. Check out this 8-step guide to see how you can increase your productivity by skipping slow application redeploys and by implementing application profiling, as you code!

Topics:

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}