Friday, September 25, 2009


I know not all testers do this, but at least where I am, testers write code and check it in. (Yes, I recognize that this is completely normal for some shops, including ours.) Now, when we check in code, we have to behave like good engineers, and that means following the guidelines of good source code management practices.

For example, today I made a change to the crontabs that run our nightly test suites. It was a simple change, just moving some start times around to accommodate some maintenance work IT is doing in the lab. In addition, we recently identified an issue where we would lose some test logs if the machines were rebooted. We traced the issue to the crontabs, where we were tee-ing the logs to /tmp (which gets cleaned out on reboot in our configuration).

So as long as I'm mucking about in the crontabs, I said I'd fix it. The bug fix is also a simple change: just add it to my change set to move times around, right? Wrong.

Instead I'm going to follow two principles:
  • Create atomic change sets
  • Isolate your change sets
Creating atomic change sets means that I put everything related in the same change set. This morning when I was moving around start times, I put all the crontab changes in a single change set, even though it was four different files.

Isolating changes ts means that the first change I checked in only makes the start time changes. It doesn't do anything else. I did a second change set to fix the bug.

The goal of creating atomic, isolated change sets is to ensure that they can later be manipulated easily and effectively. Maybe later I will merge the bug fix change set to a different branch. Maybe my start times are wrong and I need to revert that change set. Because I did them as two separate change sets, I still have that option. Because I did each separate task (changing start times and fixing a bug) as one change set, I can easily do my merges and reverts with no danger that I'm going to get myself into an inconsistent state.

Just like when you're testing, or when you're designing a test, make sure that you code for the future. A little thought now can save a lot of trouble down the line.

1 comment: