This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Naming convention for methods with JUnit

 
Andrew Romanenco
Greenhorn
Posts: 5
  • 0
  • Mark post as helpful
  • send pies
  • 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
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • 0
  • Mark post as helpful
  • send pies
  • 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
  • 0
  • Mark post as helpful
  • send pies
  • 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...
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • 0
  • Mark post as helpful
  • send pies
  • 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.
 
Cedric Beust
author
Ranch Hand
Posts: 46
  • 0
  • Mark post as helpful
  • send pies
  • 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:

http://www.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
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • 0
  • Mark post as helpful
  • send pies
  • 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".
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic