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. | |