Source posts

Fowler, MocksArentStubs

TDD's origins were a desire to get strong automatic regression testing that supported evolutionary design. Along the way its practitioners discovered that writing tests first made a significant improvement to the design process. Mockists have a strong idea of what kind of design is a good design and have developed mock libraries primarily to help people develop this design style.

And Fowler, Unit Test

Mockists insist upon solitary unit tests, while classicists prefer sociable tests. (..) Indeed using sociable unit tests was one of the reasons we were criticized for our use of the term "unit testing". I think that the term "unit testing" is appropriate because these tests are tests of the behavior of a single unit. (..) Indeed some classicist xunit testers also argue that any collaboration with external resources, such as a database or filesystem, should use doubles. Partly this is due to non-determinism risk, partly due to speed.

Table of Contents Classic Mockist Conclusion Test pyramid Design

Definition:

• assertion is done on SUT state after being exercised
• collaborators are real objects
• if not yet implemented, use a fixture, then real implementation
• use object mothers (not seeders)

Pros:

• no mock setup
• can domain-drive design (middle-out)

Cons:

• one bug cause many test to fail (anyway, regression will be detected quickly)
• complex object mothers
• lazy developers may not test at unit level
• may induce query method creation to assert state

Promoted by GOOSE book

Definition:

• assertion is done on expected behaviour (did SUT called its collaborators ?) while exercising
• collaborators are test doubles, not real objects

Pros:

• one bug cause one test to fail
• enforce testing at unit level
• support outside-in
• promote role interface
• promote OO (delegate behavior to objects - ask, don't tell)

Cons :

• mock setup at each test
• couple the SUT to implementation prematurely: which object to call ?

Classical unit test produce mini-integration test, preventing false negative (wrong expectation on mock). You should always include acceptance test to avoid this.

TDD is primarily a design methods, so TDD styles are design styles, see here