Exercise 28: sh

You are now going to continue your TDD style process, but you'll add a small hack session to start. The best method for working in TDD is to actually not write the tests first but instead to work this way:

• Spend 45 minutes doing a hack to study the problem. This is called a "spike" and is intended to iron out issues you may run into or research things you need to know.

• Plan out what you'll probably need to implement with a TODO list.

• Turn this plan into a TDD test.

• Run the test to make sure it fails.

• Write the code for the test, using what you learned from the spike.

• Audit your code and test to confirm quality.

This process is what I see TDD fanatics actually use when pressed with a problem they haven't studied before. It is also much more practical to work out a fast hack to get your mind going and to study the problem and then get serious about the work. If anyone tells you this isn't TDD, just don't tell them you did a spike first. They'll never know.