Unit Test As Tickler

In ExtremeProgramming, you write UnitTests for anything that could, in your best judgment, possibly break. Since you're not perfect and sometimes you miss one, you write more for anything that actually does break, and everything that reminds you of.

The UnitTests are run before any programmer releases any code to the system configuration, and must run at 100%. (On ChryslerComprehensiveCompensation, each programmer releases code approximately daily.)

The UnitTests can be used to check things besides works / doesn't work. For example, C3 has a unit test that checks a Smalltalk requirement: all classes implementing #hash must also implement #=. If one doesn't, the test fails, and gets fixed immediately.

We recently found a problem in the system that occurs when the year rolls over. We fixed the errors that had been made in the database. However, the fix for the code will take a week to do. It is up to the customers to decide when that work has to be done. It is certainly not urgent, and certainly provides no business value until late this year. However, the cost of forgetting to schedule the effort would be very high.

The first thing we did, of course, was to write a test that showed whether the bug existed. We always do that.

So now, we just put that test in the system, inside a guard clause that doesn't actually start checking until, say, October. Come October, if we haven't gotten around to fixing the defect (remember that it has no impact until January 2000), the test will fail. That will remind us to schedule the work, ensuring that the fix doesn't get forgotten.

You can use this trick for any chunk of work which you would like to defer, but want to be sure to fix.

Instead of trying to develop the good habit of scanning the source code for your initials or // TO DO or #needsWork, build a test that, by some deadline, will start failing if you haven't done the work. UnitTest as Automation of Good Habit.

Related idea: If you do use your initials or // ToDo or #needsWork, put a date on the same line. Write a UnitTest that looks for senders of #needsWork, checks the date in the method, and if the date has been passed, fails. UnitTest as Code Monitor.

CategoryTesting