TDDing, Fizzing and Buzzing

July 3, 2018Jamie Taylor

You’ll find an embedded player for the recording at the top of this post. This video is just over 1 hour and 40 minutes long, but it covers a the basics of Test Driven Development using FizzBuzz as an example.

Usually, creating a test driven version of FizzBuzz wouldn’t take as long as it did. However, I decided that it was a great idea to explain what was doing at each step

I also fell afoul of not saving my changes, which took a little while to figure out

Recording Date

I originally recorded this on the Jun 29th 2018.

The Purpose

How do we know that the code we write is actually correct? How can we prove that our code is still correct after we have refactored it, or added some new feature?

Testing, that’s how. But testing code manually takes a long time

plus us developers are lazy

Take the largest code project that you work on, can you imagine hoe painful it would be to test every single public method used within that code base? That’s where unit tests come in.

Unit tests can be run automatically as part of a build (local or on the build server), and even as a pre-commit check. They can even be run constantly (whenever you save a change to your code base), which helps to give instant feedback about whether the changes you have made cause any regression issues.

In this video, I wanted to create a fully unit tested implementation of FizzBuzz. I chose FizzBuzz because of it’s ubiquity and the ease of which it could be implemented.

At one point I forgot what the three rules of TDD are, the three rules are: