Question

When you’ve come up with an overall design / idea for how a part of a system should work, how do you decide where to start when doing TDD, or rather, how do you decide your first test to start with?

Answer 1

Lets assume I’m coding a class called Oven to bake my delicious Pie objects. This is how I step through the unit-test order:

1. What do I need to do to instantiate the object? In this case it would most likely be Oven oven = new Oven(); No test for this one, I suppose.
2. How do I prepare the object for use? oven.turnOn(int degrees) sounds good, I’ll do that. How do I check it? Better make oven.getTemperature(). There’s an obvious test.
3. Okay, oven is now hot enough and I want to bake my Pie. For that I need oven.bake(Pie p) so I’ll make that. But now what? I want to check if the pie is ready but rather than having oven.isPieReady() I think that oven.pastryStatus() which returns things like ‘nothing in oven’, ‘raw’, ‘almost done’, ‘cooked’ and ‘charred’ sounds good and in general should be more extendable than oven.isPieReady() so I’ll do that.

And so on and so forth. So, I’ll make my tests in order I expect to use the object refining the specification as I go. In the end I usually end up with rather simple yet powerful API which does what I want. After I’ve unit tested my API, I run coverage on my code to see what I missed and then add extra tests for those.