TDD & Mocks – Working Backwards From Expectations

[philip schwarz]

In his TDD Book, Kent Beck said:

Assert First

When should you write the asserts? Try writing them first. Don’t you just love self-similarity?

• Where should you start building a system? With stories you want to be able to tell about the finished system.
• Where should you start writing a bit of functionality? With the tests you want to pass with the finished code.
• Where should you start writing a test? With the asserts that will pass when it is done.

Jim Newkirk introduced me to this technique. When I test assert-first, I find it has a powerful simplifying effect. When you are writing a test, you are solving several problems at once, even if you no longer have to think about the implementation.

• Where does the functionality belong? Is it a modification of an existing method, a new method on an existing class, an existing method name implemented in a new place, or a new class?
• What should the names be called?
• How are you going to check for the right answer?
• What is the right answer?
• What other tests does this test suggest?

Pea-sized brains like mine can’t possibly do a good job of solving all of these problems at once. The two problems from the list that can be easily separated from the rest are, “What is the right answer?” and “How am I going to check?”

Back in 2001 William Wake, author of the Refactoring Workbook  observed and named the Arrange-Act-Assert pattern.

One thing he said was:

You might think that the Arrange is the natural thing to write first, since it comes first.

When I’m systematically working through an object’s behaviors, I may write the Act line first.

But a useful technique I learned from Jim Newkirk is that writing the Assert first is a great place to start. When you have a new behavior you know you want to test, Assert First lets you start by asking “Suppose it worked; how would I be able to tell?” With the Assert in place, you can do what Industrial Logic calls “Frame First” and lean on the IDE to “fill in the blanks.”

The Assert in ‘Arrange, Act and Assert’ is doing State Verification.

Analogously, Jason Gorman, (author, amongst other things of the Test-driven Development Maturity Model ), today posted TDD & Mocks – Working Backwards From Expectations  in which he says that when he does Behaviour Verification, i.e. ‘Arrange, Act and Verify’, he writes the verification first.