SPA Conference session: Do your tests enable change? (no, really, do your tests enable change?) | |||
| One-line description: | An investigation into how our tests impact on our ability to introduce new features into, or refactor an existing codebase by writing test driven code to implement a set of features and rotating the c | ||
| Session format: | Workshop / Simulation [read about the different session types] | ||
| Abstract: | Many people are starting to question the types of tests written as part of the Test Driven Development (TDD) process and wonder if tests can sometimes be considered harmful, making code harder to extend or refactor. We plan to investigate this and try to discover if there are any particular test patterns that are more or less helpful when we come to change existing code. The workshop takes the form of several iterations. Participants will form pairs and initially implement a set of features that will involve integrating against a third party service using test driven development techniques. Subsequent iterations will introduce new features and changes to the service’s API. Following each iteration the code will be rotated between pairs, so with each iteration pairs will inherit a different legacy code base on which to implement their changes. Can our intrepid pairs rise to the challenge and adjust their newly inherited systems to meet each fresh set of requirements? The session will round off with a discussion of what we learnt - how easy was the inherited code to change, did the tests help or hinder, did the tests aid understanding of the code - drawing up list of test patterns and anti-patterns to be aware of when coding. | ||
| Audience background: | Developers, with some TDD experience. | ||
| Benefits of participating: | Gain an insight of what how tests can help (or hinder) changing a legacy code base. | ||
| Materials provided: | Services that the pairs will write code to integrate with, GitHub repos for sharing the codebases. | ||
| Process: | Short iterations of coding, each followed by a retrospective. A final retrospective will draw conclusions from the session. | ||
| Detailed timetable: | 00:00 - 00:20 - Introduction and description of the business problem 00:20 - 00:30 - Set up, form pairs and choose language and environment (we are suggesting Java, C# or Ruby) 00:30 - 01:10 - Code 01:10 - 01:20 - Break and Swap code 01:20 - 01:40 - New Feature is introduced by the Business 01:40 - 02:30 - Code 02:30 - 02:45 - Retrospective 02:15 - 02:25 - Break and Swap Code 02:25 - 02:35 - The Business changes the service used 02:35 - 03:35 - Code 03:35 - 04:00 - Final Retrospective / Discussion of lessons learnt | ||
| Outputs: | Blogpost describing the exercise should anyone want to try it themselves. Blogpost of lessons learned and good testing patterns seen. | ||
| History: | First time given We plan to trial this informally before running the session. | ||
| Presenters | |||
| 1. Leon Hewitt 7digital |
2. Daniel Swain Wonga |
3. | |