State and interaction testing

While reading TSS this morning, I
 came across a discussion of the article Mocks Aren’t Stubs
 by Martin Fowler, whom I see as a pioneer and innovator in software development techniques.

When you write unit tests, the object you’re testing (the primary object) may need other 
 objects it depends on. You can
 mock or stub these secondary objects. A mock or stub then stands in for the secondary object in 
 the minimal form needed to test the primary one.

I used to think a mock and a stub were the same, with the minor difference that mocks
 implemented the interface of the secondary object. Martin Fowler’s article
 set me straight. The idea of mock objects comes from 
 XP (Extreme Programming) and affects how you test.

Mock objects are for interaction testing. You check the interaction between the primary and
 secondary objects against an expectation. Another widely used approach 
 is state testing, and most of the tests you’ve seen have probably used it. In state testing,
 you check that an object ends up in the expected state, such as x being
 50.

The article describes both interaction and state testing, the differences between them and the author’s 
 view of each approach. It also explains what a 
 stub and a mock each represent.