TDD Clinic: incremental design with Mock Objects.
Prerequisites: Laptop (including power cable!), Java 5 development environment
This hands-on tutorial teaches Test-Driven Development, using Mock Objects to drive the discovery of roles and responsibilities in the code.
- Test-Driven Development in context: using high-level tests to drive features, low-level tests to drive design.
- Object-Oriented Design: systems are built up from communicating objects that provide services for each other. Mock Objects helps us focus on the relationships between objects, clarifying their roles and encapsulating implementation detail.
- Test-Driven Development: using problems in testing to help us identify weaknesses in our design, learning to listen to the tests.
Mock Objects are often presented as a technique to isolate code from external dependencies and make the tests run faster. We think this is backwards, we use Mock Objects to drive the design of our code and write integration tests against third-party libraries.
We will also touch on: what should, and should not, be mocked; how to write resilient tests that express their intent and don’t break for irrelevant changes; how to use tests to identify design issues and then how to fix those issues.
The session will include a programming exercise so that the participants can try out and discuss the techniques for themselves.
We’ve run this session at XpDay London 2007 and Agile India (Bangalore). At XpDay London, the feedback was:
- Green (Loved it) 86% “Incredibly useful; the best technical I’ve heard” “Excellent, thanks.”
- Yellow (Good session) 14%
- Red 0
Intended audience and experience level: Developers (any level), Knowledge of Java. The exercises are based on jUnit4 and jMock2
We will start by presenting an overview of TDD that addresses the questions raised in the Summary, then describe the scenario that we will use for the pair programming exercise to come. This usually take 40-60 minutes depending on the level of discussion.
We will then TDD with mocks through a live demonstration, writing the first test of the exercise and then just enough code to make it pass. This usually takes 20-30 minutes.
The participants will then work in pairs to implement the first test for themselves and continue with the exercise, which will be run in iterations. After each iteration the participants will share the lessons they learned with the group and we will present more detailed explanations of the issues raised.
We will wrap up the session with a further presentation reiterating the lessons learned and looking at them in more detail, with good and bad code examples. This usually takes 30 minutes.
Originally presented with Nat Pryce and Romilly Cocking. Likely to be run with at least one other presenter.
This might fit into your TDD clinic. We usually present it as a tutorial.