If statements in tests

Question

I have a Parametrized test class with bunch of unit tests that generally control the creation of custom email messages. Right now class has a lot of test which depend on factor(s) used in parametrized class, the flow of the tests is the same for every test. The example of a test:

@Test
public void testRecipientsCount() {
    assertEquals(3, recipientsCount);
}

I had to add extra funcionality to my email class that adds some extra internal emails to the list of recipients, and that only happens for some of the cases and that leads to my problem.

Lets say I want to assert the amount of messages created. For the old test it was the same for each case, but now its different depending on cases. The most intuitive way for me was to add if statements:

@Test
public void testRecipientsCount(){
    if(something) {
        assertEquals(3, recipientsCount);
    }
    else {
        assertEquals(4, recipientsCount);
    }
}
...

but my more experienced co-worker says we should avoid ifs in test classes (and I kinda agree on that).

I thought that splitting test on two test classess may work, but that would lead to redundant code in both classes (I still have to check if non-iternal messages were created, their size, content etc.), and a few lines added for one of them.

My question is: how do I do this so I don't use if's or loads of redundant code (not using parametrized class would produce even more redundant code)?

Answer 1

A unit test should, in my opinion, test only one thing if possible. As such I'd say that if you need an if statement then you probably need more than one unit test - one for each block in the if/else code.

If possible I'd say a test should read like a story - my preferred layout (and its not my idea :-) - its fairly widely used) is:

- given:  do setup etc
- when:  the place you actually execute/call the thing under test
- expect: verify the result

Another advantage of a unit test testing only one thing is that when a failure occurs its unambiguous what the cause was - if you have a long test with many possible outcomes it becomes much harder to reason why a test has failed.

Answer 2

In my opinion a Junit should be read like a protocol. That means you can write redundant code to make the test case better readable. Write a testcase for each possible if-statement in your business logic as well as the negative cases. Thats the only way to get a 100% test coverage. I use the structure:

- testdata preparation
- executing logic
- check results
- clear data

Furthermore you should write complex asserts of big objects in own abstract classes:

abstract class YourBusinessObjectAssert{
  public static void assertYourBussinessObjectIsValid(YourBusinessObject pYourBusinessObject,       Collection<YourBusinessObject> pAllYourBusinessObject) {
for (YourBusinessObject lYourBusinessObject : pAllYourBusinessObject) {
  if (lYourBusinessObject.isTechnicalEqual(pYourBusinessObject)) {
    return;
  }
}
assertFalse("Could not find requested YourBusinessObject in List<YourBusinessObject>!", true);
}
}

it will reduce the complexity of your code and you're making it available to other developers.