Question

Regarding the classic test pattern of Arrange-Act-Assert, I frequently find myself adding a counter-assertion that precedes Act. This way I know that the passing assertion is really passing as the result of the action.

I think of it as analogous to the red in red-green-refactor, where only if I’ve seen the red bar in the course of my testing do I know that the green bar means I’ve written code that makes a difference. If I write a passing test, then any code will satisfy it; similarly, with respect to Arrange-Assert-Act-Assert, if my first assertion fails, I know that any Act would have passed the final Assert – so that it wasn’t actually verifying anything about the Act.

Do your tests follow this pattern? Why or why not?

Update Clarification: the initial assertion is essentially the opposite of the final assertion. It’s not an assertion that Arrange worked; it’s an assertion that Act hasn’t yet worked.

Answer 1

Here’s an example.

public void testEncompass() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7));
    range.encompass(7);
    assertTrue(range.includes(7));
}

It could be that I wrote Range.includes() to simply return true. I didn’t, but I can imagine that I might have. Or I could have written it wrong in any number of other ways. I would hope and expect that with TDD I actually got it right – that includes() just works – but maybe I didn’t. So the first assertion is a sanity check, to ensure that the second assertion is really meaningful.

Read by itself, assertTrue(range.includes(7)); is saying: “assert that the modified range includes 7”. Read in the context of the first assertion, it’s saying: “assert that invoking encompass() causes it to include 7. And since encompass is the unit we’re testing, I think that’s of some (small) value.

I’m accepting my own answer; a lot of the others misconstrued my question to be about testing the setup. I think this is slightly different.