SPA Conference session: Less mocking, less brittle tests

One-line description:Designing for testability and making tests less fragile in the process
 
Session format: Tutorial - 75 minutes with jus [read about the different session types]
 
Abstract:Code that is hard to maintain is a drain on productivity, manifested as reducing frequency of new or enhanced features of a system over time. As a well tested system should have two to three times more unit test code than production code, hard-to-maintain test code arguably has a greater impact than hard-to-maintain production code.

Unit testing can get a bad name when even trivial changes to production code cause lots of tests to fail. A development team's natural reaction is to remove failed tests rather than fix them. Over time, this leads to a reduction in code quality as test coverage shrinks.

For these and many other reasons, writing non-fragile tests is valuable. Based on work by Rick Janda at Zuhlke, this session aims to teach a few simple rules that make it easier, along with some refactoring routines to help convert legacy unit tests into less fragile ones (some of these involve refactoring the production code as well to make it more testable).

Along the way, we encounter such entertaining concepts as the "awkwardness scale" of classes, "mocking hell" and how to escape from it, and DRY and SOLID tests.
 
Audience background:Anyone who has worked on a project in C, C++, C#, Java, Python, Ruby or similar languages with unit tests and may have experienced the pain of having to fix broken unit tests
 
Benefits of participating:Ability to design unit tests that avoid brittleness and "smells"

Ability to design production code to be more easily testable

Ability to refactor legacy code (both production and test) for better testability and better test maintainability
 
Materials provided:Presentation slides, exercises (if time allows)
 
Process:If practical exercises are to be performed, delegates should bring along a laptop installed with their favourite or currently used IDE - e.g. IntelliJ IDEA or Eclipse for Java, Visual Studio for C/C++ or C# or Eclipse for C/C++

A few code examples will be provided for each language and delegates can work in pairs to apply the suggested refactorings.
 
Detailed timetable:Short form:
10 minute introduction
10 minute demonstration
20 minute exposition
20 minute demonstration
15 minute question-and-answer, wrap up

Longer form:
10 minute introduction
5 minute introduction to first exercise
30 minute exercise
20 minute exposition
15 minute break
5 minute introduction to second exercise
45 minute exercise
20 minute retrospective and wrap-up
 
Outputs:The presentation slides will be made available. An extended written version of the tutorial content is in preparation. Any insights gained as a result of the practical exercises and Q & A will be used to improve this. All delegates will be entitled to access the written content and can subscribe to receive an e-mail when it is updated.
 
History:A lightning version of this tutorial was delivered at an internal Zuhlke technical conference in September 2013
 
Presenters
1. Immo H√ľneke
Zuhlke Engineering Ltd
2. 3.