• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Naming convention for methods with JUnit

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello

Could you share your experience how do you (your company) test code?
We are using JUnit 4, and we have naming convention for all test methods.

after annotation @Test, we give each method name
test<OriginalMethodName>

testMakeSearch()
testReset()
and so on

but sometimes we have to make more then one test case for one method.

For example: we want to test makeSearch(...) with different parameters.

We have two possible solutions:
1. put all checks in one method, like:
public testMakeSearch() {
case1
case2
...
}

2. make one test method for each case

Variant 1 is not too good, as we will not see what cases are ok - we will see fail after first fail.

Variant 2 is better, but I don't know which naming convention to use...

testMakeSearch_case1()
testMakeSearch_case2()

but as I know "_" is not recommended in names (but not resticted)

how do you resolve this?

thanks
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hmmm, I often name mine after the input or expected result. testTooLarge() testTooSmall() testWithPunctuation(). Can't say I have a convention.
 
Andrew Romanenco
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Naming with case description is good for small classes. On fail it is 100% where the problem is.
But it will be hard to get code coverage...
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Frankly, I think that convention is far from optimal.

First, the test-prefix is redundant. The annotation already communicates that it is a test method. So why repeat that in the method name?

Second, and more importantly, in my opinion you shouldn't think about it as testing methods at all, you should think about it as testing behavior of the class. Consequently, I like my test method names to communicate the expected behavior.

So names of test methods that I would be likely to use could include

searchOnEmptyCollectionFindsNoResult
searchByNameFindsCorrectEntries
searchAfterResetFindsFirstHitAgain (or resetClearsCriteria or whatever reset is actually supposed to do)

etc. pp.
 
author
Posts: 46
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Andrew,

You can easily pass parameters to your test methods with TestNG's Data Providers, which I described in this thread:

https://coderanch.com/t/96288/Testing/most-important-feature-TestNG

Once you can pass parameters to your test methods, nothing stops you from overloading the same method name several times with different signatures...

--
Cedric
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I tend to describe the behavior I'm verifying in the name of my tests, e.g. "fooShouldBarWhenWhizGoesBang()" or "fooTellsAllBarsToCloseTooEarly()".

Sometimes I also do something like this:


That is, I name the test class according to the fixture set up with the @Before method. For example, above we have a cluster of three nodes so I name the test class like that - (Test)ClusterOfThreeNodes. The test methods, on the other hand, read out as statements about the system's behavior in the state described by the fixture (and the class name). For example, "loadBalancesBetweenAllThreeNodesUsingRoundRobin()".

So when I look at a test class, I mentally parse the class and method names as "ClusterOfThreeNodes.loadBalancesBetweenAllThreeNodesUsingRoundRobin".
reply
    Bookmark Topic Watch Topic
  • New Topic