Is it bad practice to have more than one assertion in a unit test? [closed]

Solution 1:

Sometimes I have exactly one assert per test case, but I think more often I have several assert statements.

I've seen the case that @Arkain eludes to, where a very large piece of code has a single unit test suite with just a few test cases, and they are all labeled testCase1, testCase2, etc, and each test case has hundreds of asserts. And even better, each condition usually depends upon the side-effects of previous execution. Whenever the build fails, invariably in such a unit test, it takes quite some time to determine where the problem was.

But the other extreme is what your question suggests: a separate test case for each possible condition. Depending on what you're testing, this might make sense, but often I have several asserts per test case.

For instance, if you wrote java.lang.Integer, you might have some cases that look like:

public void testValueOf() {
    assertEquals(1, Integer.valueOf("1").intValue());
    assertEquals(0, Integer.valueOf("0").intValue());
    assertEquals(-1, Integer.valueOf("-1").intValue());
    assertEquals(Integer.MAX_VALUE, Integer.valueOf("2147483647").intValue());
    assertEquals(Integer.MIN_VALUE, Integer.valueOf("-2147483648").intValue());
    ....
}

public void testValueOfRange() {
    assertNumberFormatException("2147483648");
    assertNumberFormatException("-2147483649");
    ...
}

public void testValueOfNotNumbers() {
    assertNumberFormatException("");
    assertNumberFormatException("notanumber");
    ...
}
private void assertNumberFormatException(String numstr) {
    try {
        int number = Integer.valueOf(numstr).intValue();
        fail("Expected NumberFormatException for string \"" + numstr +
             "\" but instead got the number " + number);
    } catch(NumberFormatException e) {
        // expected exception
    }
}

Some simple rules that I can think of off hand for how many assert's to put in a test case:

• Don't have more than one assert that depends on the side-effects of previous execution.
• Group asserts together that test the same function/feature or facet thereof--no need for the overhead of multiple unit test cases when it's not necessary.
• Any of the above rules should be overridden by practicality and common sense. You probably don't want a thousand unit test cases with a single assert in each (or even several asserts) and you don't want a single test case with hundreds of assert statements.

Solution 2:

No it is not a bad practice. If the method you are testing returns a class, you should test the different variables that should have been set. For this purpose you might as well use one unit test.

If, however, you are testing several features in one unit test, it won't be as clear when it fails which features caused the problem. Remember unit tests are your friend, so let them help you. Make it easily available to see what went wrong so you can go fix it.

Solution 3:

Your unit tests should be reasonably fine-grained. Typically, the fewer asserts, the more likely your test is to target a specific feature and not mix testing for multiple features in the same test. Does this mean that all tests should only have one assert? No, but I would consider it a "test smell" if I found several asserts, potentially testing multiple things in the same unit test. Treat this "smell" like you would a code smell and refactor the test to refine it so that it only tests one "thing" -- even if it requires more than one assert.

For example, I'm doing an MVC project now and one of the tests that I write is that the correct view is rendered by the action. There may actually be several of these if different code paths may result in different views. This is how I define it being the correct view: the result is the correct type and has the correct name. This requires two asserts, but I'm only testing one thing.

var result = controller.Action() as ViewResult;

Assert.IsNotNull( result );
Assert.AreEqual( viewName, result.ViewName );

I might do something similar with the model, but I would not test that the model is correct in the same test as checking the view because these are different aspects of the behavior of the code. I could change the expected model or view and by putting it in a separate test, only those tests concerned with that feature of the method need to be changed.