Unit Test Naming Conventions
Join the DZone community and get the full member experience.
Join For FreeThere 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/
Opinions expressed by DZone contributors are their own.
Comments