Record Thinking In Tests

Ron has broadened the scope of thinking activities to include typing in test cases, so he can safely claim that thinking happens all the time (while also claiming that there is usually too much thinking going on during a project). --AlistairCockburn

Still drafty, but pretty close to what I'm trying to say, considering that it's 5 AM

I'm sure we agree that thinking of test cases is thinking, and key thinking at that.

As we work through potential algorithms in our head or on the computer, we often say to ourselves things like: What will his Birthday Award be if he gets a raise on his birthday?

We have choices about these thoughts: we can analyze our algorithm in our head, or by looking at the code. When we consider a new algorithm, we can try to remember the birthday question again.

Another choice is to record the question in the UnitTests: His birthday award if he gets a raise effective on his birthday should be his age as a percentage of the new rate.

(For the record, DaimlerChrysler does not have a birthday award. I made it up.)

Now, the emergent result is that as you consider different algorithms, you don't have to recall all those questions so clearly, and you don't have to painfully analyze the code to see how it handles them. You run the tests. If it works, it works. (And if you think of another case, you make a test, not just analyze the code.)

The effect is that every special case or weird situation you ever think of on any day you work with this object is in the tests.

This means that every day in the future that you or some other person optimizes or improves or changes this object will be subject to the same excellent thinking you put in on those days, whether or not you (or this other guy) happen to be tired, forgetful, or simply human on that future day.

Now here's what's cool: when you get that idea for that slick sort down both collections, do a merge, throw all these over here all those over there, you can just type it in ... and run the tests.

So, finally, what this means is that to a very real extent, you have replaced the need for design-type thinking with your tests. Not completely, of course. But a lot of that what if this what if that kind of thinking about your code can profitably be stopped, if you RecordThinkingInTests.

--RonJeffries

Question: You've decided if the birthday bonus should be based on the salary before or after the raise, and entered a test showing that the bonus should be $526.95. Months later, changes to the code cause this test to fail. Now how does the programmer know that this is the "birthday bonus on the same day as a raise test," and how do they know (without resorting to a calculator) if you decided to base the bonus on old or new salary? There aren't any program comments or external documents describing the reasoning behind the test and its "correct" answers, are there? -- JeffGrigg

Jeff, I'd guess that the code will say ...on: person birthday, or ... on: (person birthday) - 1. Or some equivalent. So it should be pretty obvious. --Alistair

When I'm in XP mode, I always look at my unit tests first when I need to find out whether my software does something. If there isn't a test for it, I write it. Sometimes I'm surprised and it works. If it doesn't, I have work to do. Regardless, I never want to count on my software doing something that the tests don't tell me it does. I agree with Ron, tests are a knowledge base for your thinking and your software. The fact that you get software for all that thinking, rather than some speculative notes is pretty cool. -- MichaelFeathers

Unit tests make for good documentation.

An issue, though, is that some of the unit tests are very complex because they record worst-case concepts. Maybe these should be made somewhat separate?

--EricUlevik

Ah, Ron, I may have to do one of those rarest of things, and recant my comment. As I watch the way XP practitioners generate test cases, it is different from the usual test-case generation I have seen. Definitely in the category of "system thinking" (I never questioned its value, only its categorization as "thinking", i.e. in the same category as "designing").

I can even see how to apply this sort of thinking during requirements gathering, use case writing, and domain model review. In fact, I may just go do that. What a shock that will be to the folks on the team! I don't think they'll survive the shock (definitely a HighDisciplineMethodology tactic), but it will be good for them. More on this at some future date when I've internalized it better. cheers -- Alistair (7/23/99, in case you want to throw this date back at me, sometime).