Remembering Why We Do TFD/TDD
According to my client, this XML file was supposed to contain the ID of a dealer in the sender’s system. As such, my approach was going to be to develop a table to map the sender’s dealer ID to my client’s dealer ID. Once that connection was made, we could continue on with the appropriate business logic.
Examining the file revealed an element with two similar sounding sub-elements (simplified for clarity):
I knew that one of them had to be the sender’s dealerID, and I figured it would be simple enough to switch back and forth as needed, so I picked one and went on my merry way developing my mapping tables and supporting classes. JUnits ran green, life was good.
Reaching a moment of clarity, I decided that I had better figure out which was the correct field before continuing with the next piece of functionality, so I shot an email to the sender’s technical contact, who quickly confirmed which was the dealer ID from their system. To my surprise, he also indicated that the other ID was in fact my client’s dealer ID!
It turns out that there was a seperate process for synchronizing these IDs and that the incoming XML would contain both. As such, there was no need for me to do any of that mapping work.
So, what is the primary reason for doing Test First Design? Code coverage? Regression harness? Boss told you to? These are all good reasons (perhaps not the last), but the primary reason for the “First” in Test First is to clarify requirements and then encode them in an executable format.
When you run into a situation where a test that you’re writing reveals some uncertainty, don’t defer it, clarify it.