DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
The Latest "Software Integration: The Intersection of APIs, Microservices, and Cloud-Based Systems" Trend Report
Get the report
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Testing, Tools, and Frameworks
  4. Unit Test Naming Conventions

Unit Test Naming Conventions

Luigi Viggiano user avatar by
Luigi Viggiano
·
Jan. 31, 11 · Interview
Like (0)
Save
Tweet
Share
20.99K Views

Join the DZone community and get the full member experience.

Join For Free

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/

unit test

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Implementing PEG in Java
  • Chaos Engineering Tutorial: Comprehensive Guide With Best Practices
  • File Uploads for the Web (2): Upload Files With JavaScript
  • Demystifying the Infrastructure as Code Landscape

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: