« October 2005 | Main | January 2006 »

December 20, 2005

After The Show, 1988

After The Show (1988)Conventional wisdom would state that there are a few sure-fire ways to get into fights at a movie theater. One of those involves bringing a bag full of clothing to opening night of a typical summer blockbuster, placing a different article of clothing on every seat in the center of the theater and telling everyone who walks by that yes, in fact those seats are saved. Eventually there will be blood off-screen, with zero chance of romance.

Or you take it upon yourself to finish your photo assignment in a dark theater just as the credits are rolling. In my case, you do exactly this, but a few seconds before the credits finish rolling. The benefits are huge: less clothing to carry around, and fewer fist fights. After all, those who are actually close enough to do any damage (such as the well groomed contemplator sitting directly behind me) are blinded temporarily. Meanwhile, your teenage friends are too busy talking about how much they liked the film to have the time to ask what the hell you think you're doing. "That's okay," you say. "We'll figure it out it in the parking lot".

December 04, 2005

You say 'test first', I hear 'test eventually'

I think there's a common misunderstanding that "test first" doesn't really mean "test FIRST", but something more like "start testing when the code starts doing something interesting", but I think that even that short-cut is more dangerous than one might think.

For example, if you were writing a new class that contains one simple method which takes an array and reports its length, when would you start writing test cases?

  1. Before you write the class.
  2. After you write the class, but before you write the method.
  3. When your method handles a 'null' argument.
  4. When your method starts handling zero-length arrays.
  5. When your method starts handling arrays of length >0.

Purists would go with (1) and answer that since the test fails to compile, your first task would be to make the test compile. Personally I've had the best success with (2). That first test case (which might just be nothing more than an empty test with a valid setup and teardown) might already make you question the very need for the new method or class in the first place.

Based on experience, I think most people practice 4-5.. but I think starting the test writing process at that point is way too late. You've already invested some time in writing some code, and by doing so, have already raised the effort required to start from scratch if your design assumptions are wrong. More effort will be spent retrofitting a wrong assumption at that point than designing as you go.