Is it bad practice to have more than Assert in a unit test?

Question

Is it bad practice to have more than Assert in a unit test? Does it matter?

Answer 1

No it is not a bad practise, if the method you are testing, return 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. Remeber unit tests are your friend, so let them help you, by making it easily available what went wrong so you can go fix it.

Hope it answered your question.

Answer 2

I don't consider it bad practice. Unit tests can do whatever they want: assert, log to files, send insulting SMS messages to management, anything.

The possible problem is that added complexity may change the behavior of the program under test but that's rarely the case if you're being careful, and can be discovered anyway.

Answer 3

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.

Answer 4

It doesn't metter. The only thing that metter is that your unit tests will cover any possible bug.

This is an example of "over-thinking".

Answer 5

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 mode, 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.

Answer 6

Put in all the asserts in that you want. Seriously.

I try to assert every step of the way up to and including the specific goal of my test.

Answer 7

For me its very common to have more than one assert in a unit test. I usually have an assertion of a precondition and then an assert for the expected post condition.

Consider:

assert(list.isEmpty());

FetchValues(list);

assert(list.count == expectedItemCount);

AssertValuesMatch(list,expectedValues);

Yes, I could split up the two post conditions into two tests but depending on the cost of the FetchValues could slow down the overall test process needlessly.

Answer 8

A "Unit test" should test 1 unit, so be as small as possible and test only 1 certain thing. I would suggest to have only 1 assert

BUT I think its ok to have 2 assertions as long they are not one behind the other.

Bad example

public void ValidateRulesEntry_Valid_ValidConditionsFromFile()
{
    string condition = "Target.HasValue";
    string returnMessage;

    bool successFul = CodeParserTryParseCondition(condition, out returnMessage);


    Assert.IsTrue(successFul);
    Assert.IsFalse(string.IsNullOrEmpty(returnMessage));
    Assert.IsTrue(returnMessage == "OK");

}