Showing posts with label assert. Show all posts
Showing posts with label assert. Show all posts

Friday, July 16, 2010

Be more assertive when unit testing (and not when challenging me)

I tweeted this today.
A test without an assert is not a test. It leaves the intended behaviour as completely ambiguous.
Apparently I'm wrong. Some people disagreed. They were mistaken.
Let's examine their arguments.

Argument #1: Name the test method clearly enough and you don't need an assert?

public void Should_not_throw_when_doing_that_thing()
{
        var obj = new MyObj();
        var result= obj.doThatThing();       
}

To me this this has a huge gap missing in it. I'm a fan of the AAA pattern when constructing tests. Above we are only doing the Arrange and Act part.  This is why I'm not a fan of the [ExpectedException] attribute. There is no assert within the body of the message. It just doesn't read as I expect to be.

Argument #2: A test can contain no assertions, if you are mocking interactions.


[Test]
public void WhenDoingSomeThingWithAnotherThingThatWillOccur()
{
    var someThing = MockRepository.GenerateStub();
    var anotherThing = MockRepository.GenerateStub();

    someThing.Stub(x => x.Do(1)).Return(2);

    new myObj(someThing, anotherThing).Do(1);

    notificationSender.AssertWasCalled(//blah);
}

Ok this is a good point but when you are interaction testing you are still asserting that a behaviour is true. Its even there in the code.

As you can tell I'm not convinced. Can anyone provide a compelling reason to leave asserts out of tests?