CODEWITHSUNDEEP
javaunit-testingjunit
Juan Antonio Gomez Moriano
Juan Antonio Gomez Moriano

Reputation: 13833

JUnit tests for failing cases

I have been writing unit tests for python for a while, using py.test (which by the way I recommend).

Now I am doing it on java, using JUnit4. The interesting about unit testing is check how the code behaves when not everything goes as expected (unexpected data returned by a webservice, invalid input data...), on python I used to have two tests per function.

  1. The first test will check how the code behaves when everything works as expected
  2. The second test will simulate all kinds of potential problems, network problems, dirty/unexpected/invalid responses data and so on.

I usually call them test_foo() and test_foo_ko() of course java will use camelCase.

Question is, should i concentrate all the cases for a piece of code in a single test, should i split them in two as I have been doing on python or should I make a test for every-single-possible-case?

Upvotes: 1

Views: 181

Answers (2)

Marlon Bernardes
Marlon Bernardes

Reputation: 13843

I adopted the naming pattern "methodName_stateUnderTest_ExpectedBehavior". I use underscores in test names for better readability (IMO).

@Test(expected=IllegalArgumentException.class)
public void sum_negativeNumberAs1stParam_ExceptionThrown(){
     //...
}

This naming policy also implies that I write one test for each edge case.

I also dont prefix my method names with "test". That was a requirement when JUnit didn't support annotations back in the past, but it is irrelevant nowadays (considering you're using JUnit 4).

Upvotes: 2

Jeff
Jeff

Reputation: 12795

I don't have any 'official' recommendations to back me up, but the way I've always found best to do it is the every-single-possible-case option - this has the advantage that if you name them appropriately, an automated runner can immediately tell you exactly what's gone wrong - if "testCallMethodWithAParticularEdgeCaseCalledFooShouldResultInBarOutput" fails, you know that it's the Foo edge case that's the problem.

Of course, you can do that yourself with lots of logging, but why bother when you can just put it in the method name.

It also prevents accidental bleed between tests - you can be more sure that your tests are independent.

Edit: Another reason that you might want the seperate tests: you can use JUnit to cause tests to succeed if a particular exception is thrown - useful for failure cases, so you don't have to mess around with try/catch blocks.

Upvotes: 0

Related Questions