Work for a whole day making changes and now half the tests fail because you forgot the test suite more often? Be ready to throw away the changes. This is what automated testing lets us do…back up to when everything ran perfectly. It will hurt, but next time you will remember to run the test suite more often.
This recipe assumes you are using version control and are making regular commits. This idea is no good if you haven't made a commit for two weeks.
If you run your test suite at least once a day, and when it passes, you commit the changes you have made, then it becomes easy to back up to some previous point, such as the beginning of the day.
I have done this many times. The first time was the hardest. It was a new idea to me, but I realized the real value of software was now resting on my automated test suite. In the middle of the afternoon, I ran the test suite for the first time that day after having edited half the system. Over half of the tests failed.
I tried to dig in and fix the issue. The trouble was, I couldn't figure out where the issue stemmed from. I spent a couple of hours trying to track it down. It began to dawn on me that I wasn't going to figure it out without wasting loads of time.
But I remembered that everything had passed with flying colors the previous day. I finally decided to throw away my changes, run the test suite verifying everything passed, and then grudgingly go home for the day.
The next day, I attacked the problem again. Only this time I ran the tests more often. I was able to get it coded successfully. Looking back at the situation, I realized that this issue only cost me one lost day. If I had tried to ride it out, I could have spent a week and STILL probably ended up throwing things away.
Depending on how your organization manages source control, you may have to:
- Simply do it yourself by deleting a branch or canceling your checkouts
- Contact your CM team to delete the branch or the commits you made for the day
This isn't really a technical issue. The source control system makes it easy to do this regardless of who is in charge of branch management. The hard part is making the decision to throw away the changes. We often feel the desire to fix what is broken. The more our efforts cause it to break further, the more we want to fix it. At some point, we must realize that it is more costly to move forward rather than to back up and start again.
There is an axis of agility that stretches from classic waterfall software production to heavily agile processes. Agile teams tend to work in smaller sprints and commit in smaller chunks. This makes it more palatable to throw away a day of work. The bigger the task and longer the release cycle, the greater the odds are that your changes haven't been checked in since you started a task two weeks ago.
Believe me; throwing away two weeks of work is totally different than throwing away one day. I would never advocate throwing out two weeks of work.
The core idea is to NOT go home without your test suite passing. If that means you have to throw away things to make it happen, then that is what you must do. It really drives the point home of code a little/test a little until a new feature is ready for release.
We also need to reflect on why didn't we run the test suite often enough. It may be because the test suite is taking too long to run, and you are hesitating to use up that time. It may be time to Pause to refactor when test suite takes too long to run. The time I really learned this lesson was when my test suite took one-and-a-half hours to run. After I got through this whole issue, I realized that I needed to speed things up and spent probably a week or two cutting it down to a tolerable 30 minutes.
Earlier in this chapter, we talked about writing a test case that may be quite expensive to run in order to get some automated testing in action. What if our testing becomes too expensive that it is time prohibitive? After all, couldn't what we just said lead to the situation we are dealing with?
Code a little/test a little may seem to be a very slow way to proceed. This is probably the reason many legacy systems never embrace automated testing. The hill we must climb is steep. But if we can hang in there, start building the tests, make sure they run at the end of the day, and then eventually pause to refactor our code and tests, we can eventually reach a happy balance of better code quality and system confidence.