Javalobby
Did you know? DZone has great portals for Python, Cloud, NoSQL, and HTML5!

Jakub is a Java EE developer since 2005 and occasionally a project manager, working currently with Iterate AS. He's highly interested in developer productivity (and tools like Maven and AOP/AspectJ), web frameworks, Java portals, testing and performance and works a lot with IBM technologies. A native to Czech Republic, he lives now in Oslo, Norway. Jakub is a DZone MVB and is not an employee of DZone and has posted 90 posts at DZone. You can read more from them at their website. View Full User Profile

Quiz: What’s the Best Test Method Name?

12.14.2011
Email
Views: 3098
  • submit to reddit

We Recommend These Resources

Which of the following names of test methods do you think to be the best?

The best test method name:




VoteView Results
Share ThisPolldaddy.com
Quantcast

(Notice that we could leave out “payment_” from the last name if it is clear from the context, i.e. from the fixture [a fancy name for test class] name.)

According to the holy book of Clean Code, the code should make visible the intent as much as possible. According to the testing guru Kent B., a test should be telling a story to its reader – a story about how the code should be used and function. According to these two and my own experiences from reading a lot of (test) core written by other people, the last one is absolutely the best. However you have the right to disagree and discuss :-)

PS: I firmly believe that calling a test method “test()” should be punishable.

Source: http://theholyjava.wordpress.com/2011/12/13/quiz-whats-the-best-test-method-name/

Tags:
Published at DZone with permission of Jakub Holý, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Christian Schli... replied on Wed, 2011/12/14 - 8:07am

Unfortunately, my favorite answer is not available. It would be:

 testPaymentFailsForUnknownUserId()

As you can see, I prefer the test prefix in the name. It is part of the intention that should be expressed by it.

Michal Xorty replied on Wed, 2011/12/14 - 8:14am

I usually use camel case names even for tests and I like to use shorter names so I'd pick third option and properly document expected behavior in Javadoc.

/** * Payment should fail for unknown user id */ public void testPaymentUnknownUserId() ...

On the other hand I agree that fourth option is also quite good and if I were in team with such conventions, I'd get used to them.

Also, when I am testing some public API with lot of possible behaviours, I use mixed names like:
  • testApplyRules_shouldFailForAge
  • testApplyRules_shouldFailForUnknownCode
  • testApplyRules_shouldPassForValidEmployer etc.

    • Tomasz Nurkiewicz replied on Wed, 2011/12/14 - 8:43am

    I think this was the biggest advantage when switching from JUnit to ScalaTest. I can finally write:

     

    test("payment should fail for unknown userId") {
  //test code
}

test("payment should fail for unknown userId, even when payment was accepted") {
  //test code
}

test("payment should be accepted when valid useId supplied") {
  //test code
}

    Erwin Mueller replied on Wed, 2011/12/14 - 11:07am

    If you switch to groovy you can write (with the classic JUnit):

    @Test
    void "payment should fail for unknown userId"() {
    }

    Fabrizio Giudici replied on Wed, 2011/12/14 - 1:12pm

    My option is for payment_should_fail_for_for_unknown_userId(). Not using camel case for test becomes almost mandatory when you start using class names in the story (e.g. the_AccountViewController_must_tell_AccountView_when_there_are_no_money_for_the_withdraw). Syntactic sugar can be provided by Java as well - for instance, if people started looking at how TestNG is more powerful and flexible than JUnit, they'd discover that you can use annotations with a quoted name, or define a listener that will nicely log test names in whatever fashion you like (I, for instance, take the test name and replace _ with a space to print it).

    Fabrizio Giudici replied on Wed, 2011/12/14 - 1:15pm

    BTW, a trivial english question. I've always known that "must" is more assertive than "should". Not by chance, some RFC documents explicitly define this difference in assertiveness ("must" is to be used when something is mandatory and "should" when it's advisable). I personally use "must" in my test names and I'm a bit surprised to see others using "should". What am I missing?

    Jakub Holý replied on Wed, 2011/12/14 - 5:01pm

    Thank you all for the comments!

    There is of course no absolutely best naming convention and everyone may pick whatever s/he prefers but for me the winners are Scala & Groovy.

    Suck NR replied on Tue, 2011/12/20 - 11:09am in response to: fabriziogiudici

    I think the only reason why we say "should XXX" rather than "must XXX" is that 'should' has a nicer/softer sound to it; although technically I believe in these situations 'should' is a modernisation of 'shall' which has a similar imperativity as 'must'. And perhaps comes as a hangover from when requirement docs were 100000 pages long and written in legalese.

    Separate point: " if people started looking at how TestNG is more powerful and flexible than JUnit...", if people started thinking before they typed... ooo my tool is better than yours cause it does 1001 things not a 1000 ;) Seriously the difference between those two is smaller than the gap between pages in a book - lets not just start a X is better than Y thread when the actual post is about method names not test tools. You've still got to read the actual java code so it doesn't matter how friendly the output of the tool is.

     

     

     

     

    Comment viewing options

    Select your preferred way to display the comments and click "Save settings" to activate your changes.
    Controlling complexity is the essence of computer programming.
    — Brian Kernigan