Before you fix that one line bug you spotted, write an automated test instead, and make sure it's repeatable. This helps to build up insulation from our system regressing back into failures we fixed in the past.
These high level steps capture the workflow of capturing bugs in automated tests before we fix them:
- When a new bug is discovered, write a test case that recreates it. It doesn't matter if the test case is long running, complex, or integrates with lots of components. The critical thing is to reproduce the bug.
- Add it to your suite of tests.
- Fix the bug.
- Verify the test suite passes before checking in your changes.
The simplest way to introduce automated testing to an application that never had it before is to test one bug at a time. This method ensures that newly discovered bugs won't sneak back into the system later on.
The tests may have a loose knit feel instead of a comprehensive one, but that doesn't matter. What does matter is that over time, you will slowly develop a solid safety net of test cases that verify the system performs as expected.
I didn't say this would be easy. Writing an automated test for software that wasn't built with testability in mind is hard work. As mentioned in the recipe Something is better than nothing, the first test case is probably the hardest. But over time, as you develop more tests, you will gain the confidence to go back and refactor things. You will definitely feel empowered by knowing that you can't break things without knowing it.
This approach of capturing a bug with a test case is useful, but slow. But that's okay, because slowly adding testing will give you time to grow your testing skills at a comfortable pace.
Where does this pay off? Well, eventually, you will need to add some new module to your system. Doesn't this always happen? By that time, your investment in testing and test fixtures should already be paying you dividends in improvement of the quality of existing code. But you will also have a head start on testing the new module:
- You will not just know, but really understand the meaning of "test-oriented code".
- You will be able to write both the code and its tests at the same time in a very effective way.
- The new module will have a head start of higher quality and not require as much effort to "catch up" as did the legacy parts of your system.
As I stated earlier, the first test case will be very hard to write. And the next few after that won't be much easier. This makes it very tempting to throw up your hands and skip automated testing. But if you stick with it and write something that works, then you can continue building off that successful bit of effort.
This may sound like a cliché, but if you stick with it for about a month, you will start to see some results of your work. This is also a great time to start Harvesting metrics. Capturing your progress and being able to reflect on it can provide positive encouragement.