Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Reminders
I left some elements in the code to remind us where to pick up when we start working again on the code. I inserted a fail statement in the testHandFlow method in GameTest:
public void testHandFlow() {
addThreePlayers();
game.setButton(3);
...
assertNoCardsOut();
fail("need to ensure blinds are extracted properly");
}
When we come in the next morning to work on the code, we run the entire test suite. The failing test and its associated message reminds us of the things we need to work on.
But according to the rules of test-driven development (TDD), we can’t check the code in this way. All unit tests must run green all the time against the integrated source base. What we can do is check in the green code, and then quickly add the fail method as our reminder. (Note that I’m breaking the rule here—the code you can download for this installment contains the fail statement.)
I also wrote a comment in GameTest that talks about a test I think needs to be written:
// missing tests: // - use a new deck each time!
I’ve often found this kind of reminder comment to be a bad idea. A friend of mine, Jerry H., is great at making me feel stupid about my code from time to time. While sometimes it’s embarrassing, it’s always helpful to get that kind of brutal, honest feedback. Jerry recently sent me a snippet of code that I wrote well over a year ago. It contained a comment I wrote (showing my initials), something to the effect of "This code for testing purposes; make sure it gets deleted within a week." Jerry happened upon this code and sent an email with just that code snippet. The subject line of the email: "It’s still there." D’oh!
The problem is that things just don’t get done based on subtle hints. If we want something done, we’ll have to do it ourselves, not just remind ourselves—or anyone else—to do it. A comment isn’t a forceful enough reminder. We need a reminder that won’t let us off the hook until the problem is solved.
Eclipse and other tools allow us to maintain TODO comments by typing the word TODO within comments. The Eclipse TODO view summarizes all of these comments. Unfortunately, programmers don’t remember to look at the TODO list. Even if they do, they definitely don’t have any compelling reason to fix other people’s TODO problems. The TODO list continually grows in size.
Tests are a different matter. Programmers learn to be heavily dependent on a green system state. Failing unit tests cause us to hunt down the offending programmer, snarling all the way. With TDD, red bars will prevent us from effective progress until we eliminate them.
Nonetheless, I’ll still inject such reminder comments from time to time, particularly if I had a good train of thought. I strive hard to remember to remove such comments before checking in the code. And hopefully I’m working with a pair partner who can prod me to delete them.
Next segment: "It’s Just Code." Meanwhile, here’s the code (source.zip) we’ve built in this installment.