Practical TDD — First Lesson

Practical TDD — First LessonRaphael YoshigaBlockedUnblockFollowFollowingJan 8Image by Shutterstock.

comIf you are trying to learn TDD this series is for you.

On the first lesson we will start with the basics, applying TDD into a simple and small problem.

Something that does not involve classes collaborations, only a simple input and output.

I’m a .

net developer, so the example will be using xUnit and .

net core, but you can grasp the concept with any language.

You can download the final solution from here.

This is the first lesson, so I will be going very slowly, no cutting corners.

RulesFor this lesson, the only rules we are going to try to follow are the TDD ones:You shall not write production code other than to pass a failing testYou shall not write more of the production code than necessary to pass that failing test.

You shall not write more of the test than to make it fail for the right reason.

So let’s apply this into the FizzBuzz Kata — Write a program that prints the numbers from 1 to 100.

But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”.

For numbers which are multiples of both three and five print “FizzBuzz.

Given those requirements, what do you think the first test should be?My personal view is to always started by the simplest, and then go to harder parts later.

So for the TDD kata, I’m going to start with the “prints the numbers from 1 to 100”, the ones that are not “Fizz” or “Buzz” should simply be printed.

Print numbers functionalityFirst test executionRun that test, see it fail.

So now, how do I make it pass?Most people will come here and rush into returning “i.


That would violate rule number 2.

You shall not write more of the production code than necessary to pass that failing test.

Parsing it to string is not necessary to make it pass, the simplest way is:Some people might think this is too much.

It is on that situation, but jumping over it will cause bad habits if you don’t learn the rules.

So what next?.Keep going into the printing just the number:Still making it pass on the simplest way:Adding another scenario into printThen you can implement simply still:Third time is a charm.

TriangulationThen now we can introduce you to Triangulation.

You need the pattern to happen three times, so you can generalise it.

So now we are at:Red > GreenAll test still pass, so great!Triangulation will help you to avoid prematurely generalising things.

So now the basic concepts are shown, I will start speeding up:Using test casesIn xUnit there are basic two types of tests.

Facts are facts, they are truth and single execution.

Theory, are a group of arguments, that will run multiple times.

Refactoring our test to use TestCases will make it concise:Theory test executionImplementing the Fizz functionalityStill following the rules!.Tests are written first:And still implemented simply:On the same way as previously we get to:Now we have enough for Triangulation:Following the same steps of arduous work, test runs, failures, refactors and finally we get to the final result:ConclusionEven though that problem is simple, without test coverage, how would you know everything was working as expected?.Would you debug many inputs?.Honestly I think you can do better things with you time.

I hope that helps you get into TDD.

Keep posted as I progress throughout more advanced Katas like this in the future.

.. More details

Leave a Reply