Squashing Bugs
Our legacy application is big and mysterious, and we could spend an awfully long time writing characterization tests if we just started adding them aimlessly. So, assuming that we do want to grow our suite of automated tests, where should we start?
One of the best ways to start practicing with Cucumber is when you have a bug to fix. Bug reports generally come to you in the form of an example, so they’re nice and easy to translate into Cucumber scenarios.
-
Translate the bug report into a Cucumber scenario. Show the scenario to the person who reported the bug, and ask them whether it accurately describes what they were doing.
-
Wire up the step definitions and run the scenario. It should fail in the same way as the real system did when the bug was first discovered. The bug is trapped!
-
Examine the defective code, and think about what you’ll need to change. If you’re unsure or worried about breaking some existing behavior, write a characterization test scenario for it.
-
Fix the code so that the bug report scenario passes.
-
Run the characterization tests to check you didn’t break anything.
You’ll find that the bug report scenario acts as a driving force, helping you focus on the code instead of having to keep running a manual test to see whether the fix has worked.
Despite your new characterization tests, you may still find that you missed something and introduced a new bug. That happens sometimes, and it would have happened just the same if you hadn’t used any automated tests. If you use the same recipe to fix that new bug and each new bug that comes along, then gradually, over time, you’ll build up a solid suite of Cucumber scenarios. Not only will those scenarios prevent any of these bugs from recurring, but they’ll start to document the behavior of the system for anyone doing maintenance on it in the future.
We’ve just told you to use Cucumber to help you reproduce and trap bugs, so it’s quite likely that you might end up writing a new feature and calling it something like features/verify_bugfix_52553.feature. We’ve done this ourselves, and trust us—it doesn’t make for great documentation!
There are two ways around this problem. If you judge that the scenario is relevant enough to keep as business-facing documentation, then just talk to your team about where to file it away tidily in your features. If you’re adding features to a legacy system, that might will mean creating a new empty feature file about a whole big area of the system and then just adding a single scenario to describe one aspect of its behavior. That’s OK; you’ve created a space where other people can add more scenarios as they come up. Try not to mention the bug itself as you write the scenario—just describe the behavior you want as though it’s always been there.
On the other hand, if you decide that it’s such an obscure edge case that it isn’t interesting enough to remain as business-facing documentation, you can just delete the scenario once you’ve fixed the bug. That’s assuming you’ve used a unit test to cover the changes you’ve made to make the fix, so you can be safe in the knowledge that the bug won’t reappear.