Literally Unit Tests
Submitters: Antony Marcano & Andy Palmer
Level: Beginner / Intermediate
Session Type: Workshop / Dojo
Duration: 90 mins
Target Audience: Programmers; Testers; Interested Bystanders
Prerequisites: Laptop with appropriate development environment for language of participants choice (IDE, xUnit type framework, compilers etc)
In Test Driven Development, each unit test is essentially a mini-specification of what we want our code to do. Unfortunately, these tests are all too often left in a state that makes them hard for humans to read.
In this interactive tutorial, participants are guided to appreciate how important it is that they write unit tests that tell the story of the system. Participants will take away style-tips that make their tests as valuable to the next reader as they are to the author. The focus of this session is to treat unit tests not just as compilable code but also as “executable prose”.
Process/Mechanics
In this interactive tutorial, Andy and Antony help the participants to appreciate how important it is that they leave their tests in a readable state. During this session participants will practice TDD in pairs, learning how to write unit tests that tell the story of the system.
- Introduction to the topic, and presenters (5 minutes)
- Presenters explain a simple problem that the participants will solve using TDD (5 minutes)
- Pairs write tests and implementation code for simple problem - 3-5 tests (20 minutes)
- Presenters show a different problem and a “typical” unit test on the projector for group discussion - asking the group to narrate what each test is doing (5 minutes)
- Presenters demonstrate a technique for improving readability by refactoring that test (5 minutes)
- Pairs refactor their unit tests applying that technique (10 minutes)
- Presenters show what the test ended up looking like for them after applying the same technique (5 minutes)
- Repeat from step 5 for each of the remaining 3 techniques (20 minutes)
- Presenters show their final version of the unit tests for the same problem as the participants with group discussion (15 minutes)
Techniques: Composing methods that show, at a glance, what is going on Incorporating relevant setup and teardown within the test, ensuring that each test is complete within it’s own scope When to compromise on variable-scope in favor of readability Testing exceptions in a more expressive way than “expected exception” or fail() approaches Making full use of literate assertion syntax (e.g. assertThat(actual,is(expected))
Learning outcomes
- Appreciate why the readability of unit tests is so valuable
- How to express your unit tests in language more akin to how you think and speak about them
- How to reduce the translation overhead between what we want to express and how we express it in code
|
