Spend less time on maintaining the tests, and more time on writing new features
Automated tests are code too, and as such, we’re obliged to not only make them functionally correct, we need to maintain them. In TDD we’re told that refactoring the code is an important step in the process. Refactoring tests is also part of the job.
In this tutorial, we will discuss test relevancy and value, as the requirements change and when to (heaven forbid) abandon tests. We’ll see cases where we need to change the level of existing tests (unit, API, UI or any other type) as we add and change functionality and replace them with the appropriate level. We’ll see how to approach it from either test-first (BDD or TDD) or test-after.
We’ll also cover anti-patterns in automated tests. We’ll talk about code smells in tests – things that probably shouldn’t keep the way they are. Smells like duplication, inaccurate naming, inaccurate asserts, leaky tests and more. But mostly, we’ll refactor them to make them more readable, accurate and understandable for other humans. After all, they are going to stay with us for a long time.
Finally, we’ll look at how to do proper test review. How to use the time we have, when and how to do it, what to fix as we’re reviewing, and let’s not forget the human aspect – be nice to each other.
Since we’re investing so much in automated tests, we need to make sure that our teammates, not to mention our future selves, can continue using tests with ease. If “Test maintenance” is bringing you down, it’s time to get your hands dirty.
Exercises are in Java and C#.
Combo-Session: 30-minute Talk & 75-minute Workshop