Are Naming Conventions For JUnit 4+ Still Needed?

JUnit 3 used naming conventions for the identification of test methods. JUnit 4 uses annotations for that purpose, so that the prefix "test" is actually superfluous. It is not only superfluous, but also redundant.

Instead writing something like:

public void
testAverageTotalStartedThreadCount() {}

you could just skip the prefix "test" and go with the annotation only:

public void averageTotalStartedThreadCount() {}

The "test" prefixes are still generated by Eclipse and NetBeans, so if you don't like the superfluous naming, you will have to remove it manually. The "test" prefix in the test-class name, however, is still useful. It makes the search for test classes more easy.


Take it even one step further and use "should" with given-when-then:

Posted by Mateusz on November 19, 2009 at 11:33 AM CET #

A test is a specification. I use very descriptive names for my methods, and dropped Test long ago.

For example


and when using a BDD framework, this becomes more explicit.

Posted by Hadi Hariri on November 19, 2009 at 12:11 PM CET #

I don't prefix with "test" any more, it's superfluous and makes the test names harder to read.

Posted by Matthew Churcher on November 19, 2009 at 12:16 PM CET #

The "test" prefix is a convention - not a rule. It can/should be used where it is applicable, readability and comprehensibility should be the goal, not unconventionality at any price.

Posted by jiai on November 19, 2009 at 07:40 PM CET #

I still haven't seen any advantages to upgrading all my java projects to Junit 4 however. The @ adds an extra character.

Posted by Ravi on November 20, 2009 at 09:40 AM CET #


I agree with you regarding the conventions.
But: In JUnit 4+ we have already the @Test annotation it should be enough for mark test classes.



Posted by Adam Bien on November 20, 2009 at 12:56 PM CET #


Junit 4+ brings other goodness like assertThat, hamcrest and timeout. These are the actual reasons for upgrade..

thanks for your comment!,


Posted by Adam Bien on November 20, 2009 at 12:57 PM CET #

I swear I used a version of NetBeans did this for the auto-generated code (maybe a beta?)... and then it was removed.

The problem I encountered is testing methods that are defined on both the class you wish to test and a super class of your test. For a concrete example, the test will inherit from java.lang.Object and thus you may want to test the equals or hashCode methods of your target class, which leads to problems with the auto-generated code.

Of course, is it better to have uniformity by having all tests prefixed with "test" or better to deal with the special case of methods on java.lang.Object and rename them? I prefer having the auto-generated method names actually work, so I'll stick with the test prefix.

Posted by JB on November 20, 2009 at 06:37 PM CET #

Edit: I'm sorry, I meant hashCode and toString, not equals. It is the methods that have zero arguments and a non-void return type that cause the problem.

Posted by JB on November 20, 2009 at 06:47 PM CET #

The problem is that there are still tools using JUnit that have a problem with it. AFAIK there's no info on how to configure ant or Emma to cope with JUnit4 way of writing tests.

Posted by Pawel Badenski on November 23, 2009 at 01:21 AM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments