TDD – How Small Should Baby Steps Be in Test-Driven Development?

tddtesting

Today we were training TDD and found the following point of misunderstanding.

The task is for the input "1,2" return sum of numbers which is 3. What I have written (in C#) was:

numbers = input.Split(',');
return int.Parse(numbers[0]) + int.Parse(numbers[1]); //task said we have two numbers and input is correct

But other guys preferred to do it other way. First, for input "1,2" they made added the following code:

if (input == "1,2")
   return 3;

Then they introduced one more test for input "4,5" and changed implementation:

if (input == "1,2")
   return 3;
else if (input == "4,5")
   return 9;

And after that they said "Okay, now we see the pattern" and implemented what I initially did.

I think the second approach better fits the TDD definition but… should we be so strict about it? For me it is okay to skip trivial baby steps and combine them into "twinsteps" if I am sure enough that I won't skip anything. Am I wrong?

Update. I have made a mistake by not clarifing it was not the first test. There already were some tests so "return 3" actually wasn't the simplest piece of code to satisfy the requirement.

Best Answer

Write the simplest code that makes the tests pass.

Neither of you did that, as far as I can see.

Baby Step 1.

Test: For the input "1,2" return sum of numbers which is 3

Make the test fail:

throw NotImplementedException();

Make the test pass:

return 3;

Baby Step 2.

Test: For the input "1,2" return sum of numbers, which is 3

Test: For the input "4,5" return sum of numbers, which is 9

Second test fails, so make it pass:

numbers = input.Split(',');
return int.Parse(numbers[0]) + int.Parse(numbers[1]);

(Way simpler than a list of if...return)

You can certainly argue Obvious Implementation in this case, but if you were talking about doing it strictly in baby steps then these are the correct steps, IMO.

The argument is that if you don't write the second test then some bright spark could come along later and "refactor" your code to read:

return input.Length; # Still satisfies the first test

And, without taking both steps, you have never made the second test go red (meaning that the test itself is suspect).

Related Topic