Ok, don’t kill me. Breath in and listen.
As I’m working on new material for my TDD course, I got back to one of the original tips I give people about starting TDD. Forget the tests.
Doing TDD for the first time is hard. Maybe there’s another way?
And I’ll give you one right now.
Let’s say you’re writing an algorithm for multiplying a decimal number by 10 (it’s really complicated, trust me). Only the input and output are in string form. Something like:
What do you do first?
The answer is not “start coding”.
You write examples first. On paper, or as comments. Or on someone’s wall.
I promise you, if you’ve done this, you’ve already getting the biggest value of TDD, which is “it makes you think before you code”.
Because you’re looking at those and say, there’s something is missing. And you add:
Because you’re already imagining your code, and see that the zero case is different. And then you think “hmm, but what if…”
What happens if there’s a “non-defined state” here. And once you got an answer, like:
You get a better idea of the design you’re going for. And when you have enough examples (and we really do have them), we can start writing tests, or even (I know, I know) start coding.
TDD is a lot of things, but when it comes down to it, it’s just another way to write code (only the best one I know). But if you’re worried about jumping over the whole valley, you can start skipping over puddles with examples.