Don't give up on mocking!
First, I’d like to present an experience report about real-life development with mock objects: the test-driven struggle. Then I will show how to improve the TDD experience and code quality through a slightly different approach to mocking: taking a step back from the invasive nature of interaction based testing and getting closer to the way we do state based testing. Finally, I will introduce a new mock library for java: Mockito which was driven by these observations. Mockito implements what Gerard Meszaros calls a Test Spy.
Process in short:
Experience report (shows the problem) -> tutorial of a new tool (tries to fix the problem)
Intended audience:
TDD practitioners, especially those who gave up on mocking.
After the talk, listeners will:
- Write even more agile code (is it possible?)
- Write absolutely awesome test code
- Get a key to the dreamland where mocks are tamed. It’s called Mockito.
- Convert to The Mockist Church (obviously)
Presenter
Szczepan Faber spent some time in London consulting for Thoughtworks. Currently he works for Sabre Holdings in Krakow/Poland. He’s the author of mockito library, a new mocking framework for java. He is crazy about the technical side of agile: designing testable systems, TDD. He has an interesting name that only Polish people can pronounce…
Investigating mocking - the experience report: about 45 minutes (30 mins talk + 15 mins for Q/A).
There will be slides and code examples with a bit of TDD, red bar, green bar. The starting point is the latest trend I observed: quitting mock library and going back to writing mocks by hand. There will be some historical background on the mock libraries. I will stick to java world mostly with occasional look at .NET / dynamic languages.
- Why some people don’t believe in mocking? Is mocking too powerful, too invasive or simply too ugly?
- Has progress in mock libraries already ended? What’s going on in java & .NET hemispheres? What’s up with dynamic languages?
- Does test code quality vary when built using different mock libraries?
- Does application code quality vary when test driven using different mock libraries?
- What do we mock for? What would the perfect mocking tool look like?
Mockito in examples compared to classic frameworks: about 45 minutes (30 mins talk + 15 mins for Q/A).
TDD experience using Mockito: test-driving a new feature, highlighting the syntax and simplicity of the API. I will show how Mockito deals with verification failures in a way which helps maintaining the proper TDD rhythm. I will show some code written with other mocking frameworks (EasyMock, jMock) and explain the difference in TDD feel.
- What’s wrong with the expect-run-verify pattern?
- What is a “Test Spy”?
- How can a slim API of the mock library improve quality of the application code?
- What is Mockito how to use it?
Notes
The session could also go to “Tools for agility” scene but I really liked the exemplary title “The state of the art in mocking frameworks” from developer jam scene. I think it fits perfectly to what my session is about.