Prologue

How to use this book

There is not a correct -or incorrect, if we’re getting there- way of reading this book. It all comes down to your interests.

To begin with, it’s structured in four main parts that may be read separately:

The first introduces the basic concepts of TDD, as well as some strategies to learn to use and introduce this discipline in your practice.

In the second, a selection of kata or code exercises are introduce, with which the Test Driven Development concepts and techniques are explained in depth in their classic definition. They range from some that are very well known, to some that are self-made.

Each of the kata is organized as follows:

• A theoretical chapter dedicated to a relevant aspect of TDD, highlighted by that kata, over which I have put special emphasis while solving it.
• An introduction to the kata, its origin if it’s unknown, its problem statement, and a series of recommendations and points of interest about it.
• A solution developed in a different programming language and explained in detail. There’s a repository with solutions to the kata in various languages.

The third part introduces the outside-in TDD methodology. Outside-in TDD is an approach that seeks to boost the design phase, and can be applied to real project development.

The fourth part is oriented to showcasing an example of a realistic project and how can TDD be incorporated in the various stages of development and maintenance, from the creation of a minimum viable product (MVP) to defect resolution and new feature incorporation.

If your looking for a manual to learn TDD from scratch, my advice would be to read it in order. The code exercises are laid out in order to introduce the concepts in a specific progression, one that I have reached through personal experience and when I’ve taught other people to use TDD.

In the beginning, you might think that the TDD exercises are too trivial and little realistic. Keep in mind that the name kata is not coincidental. A Kata, in martial arts, is a repetitive exercise that is practiced until its movements are automated and beyond. If you practice any sport you’ll have done dozens of exercises aimed at increasing your flexibility, strength, mobility and automations, without them having a direct application to that sport. TDD kata have that same function: they prepare your brain to automate certain routines, generate specific habits, and be able to detect particular patterns in the development process.

Possibly, the outside-in approach looks that much more applicable to your daily work to you. In fact, it’s a way of developing projects using TDD. However, a solid base in classic TDD is fundamental to be successful using it. Outside-in is very close to Behavior Driven Development.

As it has been mentioned before, the various parts and exercises are relatively independent. If you already have some experience with the Test Driven Development discipline, you can jump directly to the sections or exercises that you’re interested in. Oftentimes you’ll discover something new. One of the things I’ve found out is that even though you have practiced the same exercise dozens of times, new ideas always manage to come out.

If you’re looking to introduce TDD in your or in your team’s workflow, it’s possible that you skip directly to the part about TDD in real life. It’s the one that has, to put it that way, the most dependency on previous knowledge and experience. In that case, if you think you are laking fluency in TDD, it’s possible that you must first take a look at other parts of the book.

To reach a good level of TDD performance you should practice the exercise many times. I’m not talking three or four, I’m talking dozens of times, in different parts of your professional life and, ideally, in different languages. There exists several kata repositories in which to find exercises, and you can also invent or discover your own.

It’s also advisable to look at how other people do these exercises. In the web there are available lots of kata examples done in a variety of programming languages, and it’s a great way of comparing your solutions and process.

And last but not least, one of the best ways to learn is practicing with other people. Be it in work projects, trainings, or practice communities. Live discussion of the solutions, the size of the steps, the behavior to test… will contribute to the honing and strengthening of your development process.

Assumptions

For this book some assumptions are made:

• That you have a certain experience with any programming language and with a testing environment for that language. In other words: you know how to write and run tests. It doesn’t matter that your favorite language isn’t contemplated in this book.
• This book’s examples are written in various languages, and as far as possible the usage of language-specific qualities is avoided. In fact, I am inexperienced in many of them, and therefore the code may appear very simple. On the other hand, this is something desirable in TDD, as you’ll see throughout the book.
• It’s clear to you that the objetive of the code exercise is not so much solving the problem as its proposed, which is eventually solved, but the path through which we arrive at that solution.
• You understand that there’s neither a unique solution nor a precise path in the resolution of the kata. If your solution doesn’t perfectly math the one showcased in this book, it’s not a problem.

Disclaimer

The proposed solutions to the kata are provided as explained examples of the reasoning processes that might be followed. They are not ideal solutions. When you do your version you could follow a completely different process that could be as valid (or even more) than the one presented here.

On the other hand, successive executions of the same kata by the same person could lead them to different solutions and paths. That is one of its benefits: by getting used to and automating certain thinking patterns, we can focus on more details each time and find new and more interesting points of intervention.

Likewise, as our fluency in a programming language increases, the implementations we achieve can be better and more elegant.

While preparing the kata presented in this book I have worked through several versions, in different languages, in order to find the most interesting routes and even purposefully causing some problems that I was interested in highlighting. The solution that I’ve finally decided to publish, in each case, is oriented towards some point that I wanted to accentuate about the TDD process, so it may not always be the optimal one.

That is to say, in a way, the kata come with a catch: they’re about forcing things up to the point they best achieve a didactical objetive.

In another order of thing, I have taken advantage of this project to force myself to experiment with different programming languages. In some cases, there are new to me or I have very little experience working with them, so it’s possible that the implementations are specially rough or don’t include some of there more specific and optimal features.

Basic TDD concepts

In this first part we’ll introduce the basic concepts to understand what is Test Driven Development and how it’s different from other disciplines and methodologies that use tests. We’ll also talk about how can you learn TDD, be it individually or in a team of practice community.

The first chapter has a general introduction to the process of Test Driven Development.

The chapter about basic concepts is a glossary that we’ll make use of throughout the book.

Finally, the chapter about coding-dojo and kata proposed some simple ideas to start practicing with a team or by oneself.

What is TDD and why should I care about it?

Test Driven Development is a software development methodology in which tests are written in order to guide the structure of production code.

The tests specify -in a formal, executable and exemplified manner- the behaviors that the software we’re working on should have, defining small objectives that, after being achieved, allow us to build the software in a progressive, safe and structured way.

Despite we’re talking about tests, we’re not referring to Quality Assurance (from now on: QA), even though by working with TDD methodology we achieve the secondary effect of obtaining a unitary test suite that is valid and has the maximum possible coverage. In fact, typically part of the tests created during TDD are unnecessary for a comprehensive battery of regression tests, and therefore end up being removed as new tests make them redundant.

That is to say: both TDD and QA are based in the utilizations of tests as tools, but this use is different in several respects. Specifically, in TDD:

• Tests are written before the software that they execute even exists.
• The tests are very small and their objective is to force writing the minimum amount of production code needed to pass the test, which has the effect of implementing the behavior defined by the test.
• The tests guide the development of the code, and the process contributes to the design of the system.

In TDD, the tests are defined as executable specifications of the behavior of a given unit of software, while in QA, tests are tools for verification of that same behavior.
Put in simpler words:

• When we do QA, we try to verify that the software that we’ve written behaves according to the defined requirements.
• When we do TDD, we write software to fulfill the defined requirements, one by one, so that we end up with a product that complies with them.

The Test Driven Development methodology

Although we will expand on this topic in depth throughout the book, we will briefly present the essentials of the methodology.

In TDD, tests are written in a way that we could think of as a dialogue with production code. This dialogue, the rules that regulate it, and the cycles that are generated by this way of interacting with code will be practiced in the first kata of the book: FizzBuzz.

Basically, it consists in:

• Writing a failing test
• Writing code that passes the test
• Improving the code’s (and the test’s) structure

Writing a failing test

Once we are clear about the piece of software which we’re going to work on and the functionality that we want to implement, the first thing to do is to define a very small first test that will fail hopelessly because the file containing the production code that it needs to run doesn’t even exist. While this is something that we’ll deal with in all of the kata, in the NIF kata we will delve into strategies that will help us to decide on the first tests.

Here’s an example in Go:

 1 // roman/roman_test.go
 2 package roman
 3 
 4 import "testing"
 5 
 6 func TestRomanNumeralsConversion(t *testing.T) {
 7 	roman := decToRoman(1)
 8 
 9 	if roman != "I" {
10 		t.Errorf(
11 			"Decimal %d should convert to %s, but found %s",
12 			 1,
13 			 "I", 
14 			 roman
15 		 )
16 	}
17 }

Although we can predict that the test won’t even be able to be compiled or interpreted, we’ll try to run it nonetheless. In TDD it’s fundamental to see the tests fail, assuming it isn’t enough. Our job is making the test fail for the right reason, and then making it pass by writing production code.

1 # tddbook-go/roman [tddbook-go/roman.test]
2 ./roman_test.go:6:11: undefined: decToRoman
3 
4 Compilation finished with exit code 2

The error message will indicate us what to do next. Our short-term goal is to make that error message disappear, as well as those that might come after, one by one.

 1 package roman
 2 
 3 import "testing"
 4 
 5 func TestRomanNumeralsConversion(t *testing.T) {
 6 	roman := decToRoman(1)
 7 
 8 	if roman != "I" {
 9 		t.Errorf(
10 			"Decimal %d should convert to %s, but found %s",
11 			1,
12 			"I",
13 			roman
14 		)
15 	}
16 }
17 
18 func decToRoman(decimal int) string {
19 	
20 }

For instance, after introducing the decToRoman function, the error will change. Now it’s telling us that it should return a value:

1 # tddbook-go/roman [tddbook-go/roman.test]
2 ./roman_test.go:16:1: missing return at end of function
3 
4 Compilation finished with exit code 2

It could even happen that we get an unexpected message, such as that we’ve tried to load the Book class and it turns out that we had mistakingly created a filled named brok. That’s why it’s so important to run test, and see if it fails and how does it do it exactly.

 1 package roman
 2 
 3 import "testing"
 4 
 5 func TestRomanNumeralsConversion(t *testing.T) {
 6 	roman := decToRoman(1)
 7 
 8 	if roman != "I" {
 9 		t.Errorf(
10 			"Decimal %d should convert to %s, but found %s",
11 			1,
12 			"I",
13 			roman
14 		)
15 	}
16 }
17 
18 func decToroman(decimal int) string {
19 	
20 }

This code results in the following message:

1 # tddbook-go/roman [tddbook-go/roman.test]
2 ./roman_test.go:6:11: undefined: decToRoman
3 ./roman_test.go:16:1: missing return at end of function
4 
5 Compilation finished with exit code 2

This error tells us that we have misspelled the name of the function, so we start by correcting it:

 1 package roman
 2 
 3 import "testing"
 4 
 5 func TestRomanNumeralsConversion(t *testing.T) {
 6 	roman := decToRoman(1)
 7 
 8 	if roman != "I" {
 9 		t.Errorf(
10 			"Decimal %d should convert to %s, but found %s", 
11 			1, 
12 			"I", 
13 			roman
14 		)
15 	}
16 }
17 
18 func decToRoman(decimal int) string {
19 	
20 }

And we can continue. Since the test states that it expects the function to return “I” when we pass it 1 as an input, the failed test should indicate us that the actual result doesn’t match the expected one. However, at the moment, the test is telling us that the function doesn’t return anything. It’s still a compilation error and still not the correct reason to fail.

1 # tddbook-go/roman [tddbook-go/roman.test]
2 ./roman_test.go:16:1: missing return at end of function
3 
4 Compilation finished with exit code 2

To make the test fail for the reason that we expect it to, we have to make the function return a string, even if it’s an empty one.

 1 package roman
 2 
 3 import "testing"
 4 
 5 func TestRomanNumeralsConversion(t *testing.T) {
 6 	roman := decToRoman(1)
 7 
 8 	if roman != "I" {
 9 		t.Errorf(
10 			"Decimal %d should convert to %s, but found %s",
11 			1, 
12 			"I", 
13 			roman
14 		)
15 	}
16 }
17 
18 func decToRoman(decimal int) string {
19 	return ""
20 }

So, this change turns the error into one related with the test definition, as it’s not obtaining the result that it expects. This is the correct reason for failure, the one that will force us to write the production code that will pass the test.

1 === RUN   TestRomanNumeralsConversion
2 --- FAIL: TestRomanNumeralsConversion (0.00s)
3     roman_test.go:9: Decimal 1 should convert to I, but found 
4 FAIL
5 
6 Process finished with exit code 1

And so we would be ready to take the next step:

Writing code that passes the test

As a response to the previous result, we write the production code that is needed for the test to pass, but nothing else. Continuing with our example:

 1 package roman
 2 
 3 import "testing"
 4 
 5 func TestRomanNumeralsConversion(t *testing.T) {
 6 	roman := decToRoman(1)
 7 
 8 	if roman != "I" {
 9 		t.Errorf(
10 			"Decimal %d should convert to %s, but found %s", 
11 			1, 
12 			"I", 
13 			roman
14 		)
15 	}
16 }
17 
18 func decToRoman(decimal int) string {
19 	return "I"
20 }

After making the test pass we can start creating the file that’ll contain the unit under test. We could even rerun the test now, which probably would cause the compiler or the interpreter to throw a different error message. At this point everything depends a bit on circumstances, such as conventions in the language we’re using, the IDE we’re working with, etc.

In any case, it’s a matter of taking small steps until the compiler or interpreter is satisfied and can run the test. In principle, the test should run and fail indicating that the result received from the unit of software doesn’t match the expected one.

At this point there’s a caveat, because depending on the language, the framework, and some testing practices, the concrete manner of doing this first test may vary. For example, there are test frameworks that just require for the test to not throw any errors or exceptions to succeed, so a test that simply instantiates an object or invokes any of its methods is enough. In other cases it’s necessary that the test includes an assertion, and if none is made it’s considered as not passing.

In any case, this phase’s objective is making the test run successfully.

With the Prime Factors we’ll study the way in which production code can change to implement new functionality.

Improve the structure of the code (and tests)

When every test passes, we should examine the work done so far and check if it’s possible to refactor both the production and test code. Here we apply the usual principles: if we detect any smell, difficulty in understanding what’s happening, knowledge duplication, etc. we must refactor the code to make it better before continuing.

Ultimately, the questions at this point are:

• Is there a better way to organize the code that I’ve just written?
• Is there a better way to express what this code does and make it easier to understand?
• Can I find any regularity and make the algorithm more general?

For this reason, we should keep every test that we’ve written and made pass. If any of them turn red we would have a regression in our hands and we would have spoiled, so to speak, the already implemented functionality.

It’s usual not to find many refactoring opportunities after the first cycle, but don’t get comfortable just yet: there’s always another way of seeing and doing things.

Tras el primer ciclo es normal no encontrar muchas oportunidades de refactor, pero no te fíes: siempre hay otra manera de ver y hacer las cosas. As a general rule, the earlier you spot opportunities to reorganize and clean up your code and do so, the easier development will be.

For instance, we’ve created the function under test in the same file as the test.

 1 package roman
 2 
 3 import "testing"
 4 
 5 func TestRomanNumeralsConversion(t *testing.T) {
 6 	roman := decToRoman(1)
 7 
 8 	if roman != "I" {
 9 		t.Errorf(
10 			"Decimal %d should convert to %s, but found %s", 
11 			1, 
12 			"I", 
13 			roman
14 		)
15 	}
16 }
17 
18 func decToRoman(decimal int) string {
19 	return "I"
20 }

Turns out there’s a better way to organize this code, and it is creating a new file to contain the function. In fact, it’s a recommended practice in almost every programming language. However, we may have skipped it at first.

1 //roman/roman.go
2 
3 package roman
4 
5 func decToRoman(decimal int) string {
6 	return "I"
7 }

And, in the case of Go, we can convert it in an exportable function if its name is capitalized.

1 package roman
2 
3 func DecToRoman(decimal int) string {
4 	return "I"
5 }

To delve further into everything that has to do with the refactor when working we’ll have the Bowling Game kata.

Repeat the cycle until finishing

Once the production code passes the test and is as nicely organized as it can be in this phase, it’s time to choose other functionality aspect and create a new failing test in order to describe it.

This new test fails because the existing code doesn’t cover the desired functionality and introducing a change is necessary. Therefore, our mission now is to turn this new test green by making the necessary transformations in the code, which will be small if we’ve been able to size our previous tests properly.

After making this new test pass, we search for refactoring opportunities to achieve a better code design. As we advance in the development of the piece of software, we’ll see that the possible refactorings become more and more significant.

In the first cycles we’ll begin with name changes, constant and variable extraction, etc. Then we’ll advance to introducing private methods or extracting certain aspects as functions. At some point we’ll discover the necessity of extracting functionality to helper classes, etc.

When we’re satisfied with the code’s state, we keep on repeating the loop as long has we have remaining functionality to add.

When does development end in TDD?

The obvious answer to this question could be: when all the functionality is implemented.

But, how do we know this?

Kent Beck suggested making a list of all of the aspects that would have to be fulfilled to consider the functionality as complete. Every time any one of them is attained it’s crossed off the list. Sometimes, while advancing in the development, we realize that we need to add, remove or change some elements in the list. It’s good advice.

There is a more formal way of making sure that a piece of functionality is complete. Basically, it consists in not being able to create a new failing test. Indeed, if an algorithm is implemented completely, it will be impossible to create a new test that can fail.

What is not Test Driven Development

The result or outcome of Test Driven Development is not creating flawless software free of any defect, although many of them are prevented; or generating a suite of unitary tests, although in practice it’s indeed obtained and has a coverage that can even reach 100% (with the tradeoff that it may have redundancy). But, none of these are TDD’s objectives, in any case they’re just certainly beneficial collateral effects.

TDD is not Quality Assurance

Even though we use the same tools (tests), we use them for different purposes. In TDD, testing guides development, setting specific objectives that are reached by adding or changing code. The result of TDD is a suite of tests that can be used in QA as regression tests, although it’s frequent that we have to retouch those tests in some way or other. In some cases to delete redundant tests, and in others to ensure that the casuistries are well covered.

In any case, TDD helps enormously in the QA process because it prevents many of the most common flaws and contributes to building well structured and loosely coupled code, aspects that increase software reliability, our ability to intervene in case of errors, and even the possibility of creating new tests in the future.

TDD doesn’t replace design

TDD is a tool to aid in software design, but it doesn’t replace it.

When we develop small units with some very well defined functionality, TDD helps us establish the algorithm design thanks to the safety net provided by our tests.

But when considering a larger unit, a previous analysis that leads us to a “sketch” of the main elements of the solution allows us to have a development frame.

The outside-in approach tries to integrate the design process within the development one, using what Sandro Mancuso tags as Just-in-time design: we start from a general idea about how the system will be structured and how it will work, and we design within the context of the iteration that we’re in.

How TDD helps us

What TDD provides us is a tool that:

• Guides the software development in a systematic and progressive way.
• Allows us to verifiable claims about whether the required functionality has been implemented or not.
• Helps us avoid the need to design all of the implementation details in advance, since it’s a tool that helps the software component design in itself.
• Allows us to postpone decisions at various levels.
• Allows us to focus in very concrete problems, advancing in small steps that are easy to reverse if we introduce errors.

Benefits

Several studies have shown evidence that suggests that the application of TDD has benefits in development teams. It’s not conclusive evidence, but research tends to agree that with TDD:

• More tests are written
• The software has fewer flaws
• The productivity is not diminished, it can even increase

It’s quite difficult to quantify the advantages of using TDD in terms of productivity or speed, but subjectively, many benefits can be experienced.

One of them is that the TDD methodology can lower the cognitive load of development. This is so because it favors the division of the problem in small tasks with a very defined focus, which allows us to save the limited capacity of our working memory.

Anecdotal evidence suggests that developers and teams introducing TDD reduce defects, diminish time spent on bugs, increase deployment confidence, and productivity is not adversely affected.

References

• Test Driven Development¹
• Why Test-driven Development²
• Test driven development: empirical body of evidence³
• Does Test-Driven Development Really Improve Software Design Quality⁴
• 6 Misconceptions about TDD – Part 1. TDD Brings Little Business Value and Isn’t Worth it⁵
• TDD is about design, not testing⁶
• Does TDD really lead to good design?⁷
• Using TDD to influence design⁸

Basic concepts

Next we’ll define some of the concepts that are used throughout the book. They must be understood within the context of Test Driven Development.

Test

A test is a small piece of software, usually a function, which runs another piece of code and verifies if it produces an expected result or effect. A test is, basically, an example of usage of the unit under test in which a scenario is defined and the tested unit is executed to see if the results matches what we had in mind.

Many languages use the notion of TestCase, a class that groups several related tests together. In this approach, each method is a test, although it’s usual to refer to the test case as just “test”.

Test as specification

A test as specification utilizes usage examples from the tested piece of software in order to describe how it should work. Significant examples are used, above all, but it’s not always done in a formal way.

It’s opposite to the test as verification, typical of QA, in which the piece of software is tested by choosing the test cases in a systematic manner to verify that it fulfills what’s expected of it.

Failing test

A failing test is a specification that cannot be fulfilled yet because the production code that lets it pass hasn’t been added. Testing frameworks typically picture them with a red color.

Passing test

A passing test is a specification that runs production code which generates an expected result or response. Testing frameworks typically give them a green color.

Types of tests

Unit tests

They are tests that test an isolated unit of software; their dependencies are doubled to keep their influence on the result controlled.

Integration tests

Integration tests usually test groups of software units, so that we can verify their communication and combined action.

Acceptance tests

Acceptance tests are integration tests that test a software systems as if they were yet another of their consumers. We normally write them depending on the business’s interests.

Test Case

It’s a class that groups several tests together.

Test Suite

It’s a set of test and/or test cases that can usually be executed together.

Production code

In TDD we use the name “production code” to refer to the code that we write to make tests pass and which, eventually, will end up being executed in a production system.

Software unit

Software unit is a quite flexible concept that we have to interpret within a context, but it usually refers to a piece of software that can be executed in a unitary and isolated manner, even if when it’s composed of many elements.

Subject under test

The software unit that is exercised in a test. There’s a discussion about what is the scope of a unit. At one extreme there are those who consider that a unit is a function, a method, or even a class. However, we can also consider as unit under test a set of functions or classes that are tested through the public interface of one of them.

Refactoring

A refactoring is a change in code that doesn’t alter its behavior or its interface. The best way to ensure this is having at least one test that exercises the piece of code that is being modified, so that after each change we make sure that the test keeps passing. This proves that the behavior hasn’t changes even though the implementation has been modified.

Some techniques or refactoring patterns are described in compilations such as these, from Refactoring Guru, or the classic book from Martin Fowler.

Automatic refactoring

Precisely because some refactorings are very well identified and characterized, it’s been possible to develop tools that can execute them automatically. These tools are available in the IDE.

Coding-dojo y katas

Kata

In the software world we call kata to design and programming exercises that pose relatively simple and limited problems that we can use to practice development methodologies.

This term is a borrowing from the Japanese word that refers to the training exercises typical of martial arts. Its introduction is attributed to Dave Thomas (The Pragmatic Programmer)¹, referring to the completion of small code exercises, repeated over and over again until achieving a high degree of fluency or automation.

Applied to TDD, kata seek to train the test-production-refactoring as well as the ability to add behavior by means of small code increments. These exercises will help you divide functionality in small parts, choose examples, advance in the project step by step, switch priorities depending on the information provided by the tests, etc.

The idea is to repeat the same kata many times. On top of gaining fluency in the application the process, in each of the repetitions there’s the possibility of discovering new strategies. With repeated practice, we’ll favor the development of certain habits and pattern recognition, automating our development process to a certain extent.

You can train with kata by yourself or with others. A systematic way of doing this is through a Coding Dojo.

Coding-dojo

A coding-dojo is a workshop in which a group of people, regardless of their level of knowledge, perform a kata in a collaborative and non-competitive way.

The idea of Coding Dojo or Coder’s Dojo was introduced in the XP2005 conference by Laurent Bossavit y Emmanuel Gaillot.

The basic structure of a coding-dojo is pretty simple:

• Presentation of the problem, explanation of the exercise (5-10 min)
• Coding session (30-40 min)
• Sharing of the status of the exercise (5-10 min)
• The coding session continues (30-40 min)
• Sharing and review of the achieved solutions

The coding session can be structured in several ways:

• Prepared kata. A presenter explains how to solve the exercise, but relying on the feedback from the attendants. No progress is made until consensus is reached. It’s a very suitable way of working when the group is just starting out and few people are familiar with the methodology.
• Randori kata. The kata is done in paring using some system to switch between a driver (on the keyboard) and a co-pilot. The rest of the attendants collaborate by making suggestions.
• Hands-on workshop. One alternative is to make the participants form pairs and work on the kata collaboratively. Halfway through the exercise, a few-minutes break is taken in order to discuss the work that has been done. At the end of the session, all of the different solutions are presented (at whatever step of the assignment each team has arrived). Participants can choose their preferred programming language, so it’s a great opportunity for those that are looking to get started with a new one. It can also be a good approach for beginners if the pair members have different levels of experience.

Advice for completing the kata individually

In the beginning it may be a good idea to attend directed kata. Essentially, it’s a kata performed by an expert in the shape of a live coding session where they explain or comment the different steps with the audience, in such a way that you can easily see the dynamic in action. If you don’t have this possibility, which may be the most common scenario, it’s a good idea to watch some kata on video. You will find some links in the chapters dedicated to each kata.

Above all, the goal of the kata is to exercise the TDD discipline, the application of the three laws, and the red-green-refactor cycle. Production code is actually less important, in the sense that it’s not the main objective of the learning, although it will always be correct as long as the tests pass. However, every execution of the kata can lead us to discover new details and new ways of facing each phase.

Namely, the kata are designed to learn to develop software using tests as a guide, and to train the mindset, the reasonings, and the analysis that help us perform this task. In general, developing a good TDD methodology will help us write better software thanks to the constraints it imposes.

Obviously, the first tries will take their time, you will get into paths with no apparent return, or you will straight up skip some of the steps of the cycle. When this happens, you just have to go back or start over from scratch. These are exercise that don’t have a unique correct answer.

In fact, every programming language, approach, or test environment could favor some solutions over the others. You can perform a kata several times, trying to assume different starting assumptions in each try, or applying different paradigms or conditions.

If you reach points in which you can choose between different courses of actions, take note of them in order to repeat the exercise, and try a different path later to see where it leads you.

In TDD it’s really important to focus on the here and the now that each failing tests defines, and not get anxious about reaching the final objective. This doesn’t mean putting it aside or dedicating ourselves to something else. It simply means that we have to tread that path step by step, and doing it like that will take us to the finish line almost without us realizing, with much less effort and more solidity. Acquiring this mindset, dealing only with the problem in front of us, will help us reduce stress and think more clearly.

If possible, try repeating the same kata using different languages, even different testing frameworks. The two best known families are:

• xSpec, which are oriented to TDD and tend to favor testing by example, providing specific syntax and utilities. Their handicap is that they don’t usually work well for QA.
• xUnit, which are the most generic testing frameworks, albeit more QA oriented. Nevertheless, they can be used in TDD without any problems.

How to introduce TDD in development teams

Introducing the TDD methodology in development teams is a complex process. Above all, it’s important to contribute to generating a culture that’s open to innovation, to quality, and to learning. The greatest reluctance often comes from a fear of TDD slowing down the development, or that at first they cannot see direct applications to the daily problems.

I personally believe that using both formal and informal channels can be of interest. Here are some ideas.

• Establishing a weekly time, one or two hours, for a coding-dojo open to the whole team. Depending on the level of expertise, it could start with directed kata, hands-on type sessions, or the format that seems the most appropriate to us. Ideally, several people would be able to get them moving.
• Bringing on experienced people into the teams who could help us introduce TDD in pairing or mob-programming work sessions, guiding their coworkers.
• Organizing specific trainings, with external help if people with enough experience aren’t available.
• Introducing (if there isn’t one already) a technical blog in which to publish articles, exercises, and examples about the topic.

Kata repositories

• Katalyst²
• Kata-log³
• Coding dojo⁴
• Codekata⁵
• Agile kata⁶

References

• The Programming Dojo⁷
• What is coding dojo⁸
• The Coder’s Dojo – A Different Way to Teach and Learn Programming - Abstract⁹

Classic TDD

In this part we present a series of code exercises with which we’ll explore in depth how Test Driven Development is done.

We’ll use the discipline’s classic style or approach. TDD is a software development methodology re-discovered by Kent Beck, based on the way that the first computer programs used to be built. Then, calculations were first carried out by hand, so as to have the reference of the expected the result that would have to be reproduced in the computer. In TDD, we write a very simple program that tests that the result of other program matches the expected one. The key here is that this program hasn’t been written yet. It’s that simple.

The methodology was presented by Beck in his book TDD by example, in which, among other things, teaches how to build a testing framework using TDD. Subsequently, various authors have contributed to the refinement and systematization of the model.

The laws of TDD

Since the introduction of the TDD methodology by Kent Beck, there has been an effort to define a simple framework that serves as a guide for its application in practice.

Initially, Kent Beck proposed two very basic rules:

• Don’t write a line of new code unless you first have a failing automated test.
• Eliminate duplication.

That is, to be able to write production code, first we must have a test that fails and that requires us to write that code, precisely because that’s what’s needed to pass the test.

Once we’ve written it and checked that the test passes, our effort goes towards reviewing the written code and eliminating duplication as much as possible. This is very generic, because on the one hand it refers to refactoring, and in the other hand, to the coupling between the test and the production code. And being so generic, it’s hard to translate to practical actions.

On top of that, these rules don’t tell us anything about how big the jumps in the code involved in each cycle should be. In his book, Beck suggests that the steps -or baby steps- can be as small or as big as we find them useful. in general, he recommends using small steps when we’re unsure or have little knowledge about the algorithm, while allowing larger steps if we have enough experience and knowledge to be sure about what to do next.

With time, and starting from the methodology learnt from Beck himself, Robert C. Martin established the “three laws”, which not only define the action cycle in TDD, but also provide some criteria about how large the steps should be in each cycle.

• It’s not allowed to write any production code unless it passes a failing unit test
• It’s not allowed to write more than the one unit test that’s sufficient to fail; and compilation errors are failures
• It’s not allowed to write more production code than necessary to pass the one failing unit test

The three laws are what make TDD different to simply writing tests before code.

These three laws impose a series of restrictions whose objective is to force us to follow a specific order and workflow. The define several conditions that, if they’re fulfilled, generate a cycle and guide our decision-making. Understanding how they work will help us to make the most out of TDD to help us produce quality code that we’re able to maintain.

Theses laws have to be fulfilled all at the same time, because they work together.

The laws in detail

It’s not allowed to write any production code unless it passes a failing unit test

The first law states that we can’t write any production code unless it passes an existing unit test that is currently failing. This implies the following:

• There has to be a test that describes a new aspect about the behavior of the unit that we’re describing.
• This test must fail because there isn’t anything that makes it pass in the production code.

In short, the first law forces us to write a test that defines the behavior that we’re about to implement in the unit of software that we want to develop, all before having to consider how to do it.

Now, how should this test be?

It’s not allowed to write more than the one unit test that’s sufficient to fail; and compilation errors are failures

The second law tells us that the test must be sufficient to fail, and that we have to consider compilation errors as failures (or their equivalent in interpreted languages). For examples, among these errors there would be some as obvious as that the class or function doesn’t exist or hasn’t been defined yet.

We must avoid the temptation of writing and skeleton of the class or function before writing the first test. Remember that we’re talking about Test Driven Development. Therefore, it’s the tests that tell us what production code to write and when to write it, and not the opposite.

For the test, “being sufficient to fail” means that it must be very small in several ways, and this is something that is quite difficult to define at first. Frequently we talk about the “simplest” test, the simplest case, but it’s not exactly this way.

What conditions must a TDD test meet, especially the first one?

Well, basically it should force us to write the minimum possible amount of code that can be executed. That minimum, in OOP, would be to instantiate the class that we want to develop without worrying about any further details, for now. The specific test will vary a little depending on the language and testing framework that we’re using.

Let’s take a look at this example from the Leap Year kata, where we write code to find out if a year is a leap year or not. In the example, my intention is to create a Year object to which I can ask if it’s a leap year by sending it the message IsLeap. I’ve come upon this exercise in several kata compilations. For this chapter the examples will be written in C#.

The rules are:

• The years not divisible by 4 aren’t leap years (for example, 1997).
• The years divisible by 4 are leap years (1999), unless:
• If they’re divisible by 100 they aren’t leap years (1900).
• If they’re divisible by 400 they are leap years (2000).

Our goal would be to be able to use Year objects in this manner:

1 var year = new Year(1996);
2 
3 if (year.IsLeap()) {
4 	// do something
5 }

The usual impulse is to try and start in the following way, because it looks like it’s the example of the simplest possible case.

 1 using System;
 2 using System.Runtime.Remoting.Metadata.W3cXsd2001;
 3 using NUnit.Framework;
 4 
 5 namespace LeapYear
 6 {
 7     public class Tests
 8     {
 9         [Test]
10         public void ShouldNotBeLeapYear()
11         {
12             var year = new Year(1997);
13             Assert.False(year.IsLeap())
14         }
15     }
16 }

However, it’s not the simplest test that could fail for only one reason. Actually, it can fail for at least five different reasons:

• The Year class doesn’t exist yet.
• It also wouldn’t accept parameters passed by the constructor.
• It doesn’t answer to the IsLeap message.
• It could return nothing.
• It could return an incorrect response.

That is, we can expect the test to fail for those five causes, and only the fifth is the one that’s actually being described by the test. We have to reduce them to just one.

In this case, it’s very easy to see that there’s a dependency between the various causes of failure, in such a way that for one to surface, the previous ones have to be solved. Obviously, it’s necessary to have a class that we can instantiate. Therefore, our first test should be much more modest and just expect that the class can be instantiated:

 1 using System;
 2 using System.Runtime.Remoting.Metadata.W3cXsd2001;
 3 using NUnit.Framework;
 4 
 5 namespace LeapYear
 6 {
 7     public class Tests
 8     {
 9         [Test]
10         public void CanInstantiate()
11         {
12             new Year();
13         }
14     }
15 }

If we ran this test, we would see it fail for obvious reasons: the class that we try to instantiate isn’t anywhere to be found. The test is failing by a compilation -or equivalent- problem. Therefore, it could be a test that’s sufficient to fail.

Throughout the process we’ll see that this test is redundant and that we can do without it, but let’s not get ahead of ourselves. We still have to make it pass.

It’s not allowed to write more production code than necessary to pass the one failing unit test

The first and the second laws state tha we have to write a test and tell us how that test should be. The third law tells us how production code should be: the condition is that it must pass the test that we’ve written.

It’s very important to understand that it’s the test the one that tells us what code we need to implement, and therefore, even though we have the certainty that it’s going to fail because we don’t even have a file with the necessary code to define the class, we still must execute the test and expect its error message.

That is: we must see that the test, indeed, fails.

The first thing that it’ll tell us when trying to run it is that the class doesn’t exist. In TDD, that’s not a problem, but rather an indication about what we have to do: add a file that contains the definition of the class. It’s possible that we’re able to generate that code automatically using the IDE tools, and it would be advisable to do it that way.

In our example, the message of the test says:

1 The type or namespace name 'Year' could not be found 
2 (are you missing a using directive or an assembly reference?)

And we would simply have to create the Year class.

 1 using System;
 2 using System.Runtime.Remoting.Metadata.W3cXsd2001;
 3 using NUnit.Framework;
 4 
 5 namespace LeapYear
 6 {
 7     public class Tests
 8     {
 9         [Test]
10         public void CanInstantiate()
11         {
12             new Year();
13         }
14     }
15 
16     public class Year
17     {
18     }
19 }

At this point we run the test again to make sure it passes from red to green. In many languages this code will be enough. In some cases you might need something more.

If this is so and the test passes, the first cycle is complete and we can move on to the next behavior, unless we think that we have the chance to refactor the existing code. For example, the usual thing to do here would be to move the Year class to its own file.

1 namespace LeapYear
2 {
3     public class Year
4     {
5     }
6 }

If the test hasn’t passed, we’ll look at the message of the failed test and we’ll act accordingly, adding the minimum code necessary for it to finally pass and turn green.

The second test and the three laws

When we’ve managed to pass the first test by applying the three laws, we might think that we haven’t really achieved anything. We haven’t even tackled the possible parameters that the class might need in order to be constructed, be them data, collaborators -in the case of services-, or use cases. Even the IDE is complaining that we’re not assigning the instantiated object to any variable.

However, it’s important to adhere to the methodology, especially in these first stages. With practice and the help of a good IDE, the first cycle will have taken a few seconds at most. In these few seconds we’ll have written a piece of code that, while certainly very small, is completely backed by a test.

Our goal still is to let the tests dictate what code we must write to implement each new behavior. Since our first test already passes, we have to write the second.

Applying the three laws, what comes next is:

• Write a new failing test that defines a behavior
• That this test is the smallest possible one that still forces us to make a change in the production code
• Write the minimum and sufficient production code to pass the test

Which could be the next behavior that we need to define? If in the first test we’ve forced ourselves to write the minimum necessary code to instantiate the class, the second test can lead us through two paths:

• Force us to write the necessary code to validate constructor parameters and, therefore, be able to instantiate an object with everything that it needs.
• Forcing us to introduce the method that executes the desired behavior.

This way, in our example, we could simply make sure that Year is able to answer the IsLeap message.

 1 using System;
 2 using System.Runtime.Remoting.Metadata.W3cXsd2001;
 3 using NUnit.Framework;
 4 
 5 namespace LeapYear
 6 {
 7     public class Tests
 8     {
 9         [Test]
10         public void CanInstantiate()
11         {
12             new Year();
13         }        
14         
15         [Test]
16         public void CanRespondToIsLeapMessage()
17         {
18             var year = new Year();
19             year.IsLeap();
20         }
21     }
22 }

The test will throw this error message:

1 'Year' does not contain a definition for 'IsLeap' and no accessible extension...

Which tells us that the next step should be to introduce the method that answers that message:

1 namespace LeapYear
2 {
3     public class Year
4     {
5         public void IsLeap()
6         {
7         }
8     }
9 }

The test passes, indicating that the objects of type Year can now attend to the IsLeap message.

Having arrived at this point, we could ask ourselves: what if we don’t obey the three laws of TDD?

Violations of the three laws and their consequences

Disregarding the easy joke that we’ll end up fined or in jail for not following the laws of TDD, the truth is that we’d really have to suffer some consequences.

First law: writing production code without having a test

The most immediate consequence is that we break the red-green cycle. The code that we write is no longer guided or covered by tests. In fact, if we wish to have that part tested, we’ll have to write “a posteriori” tests (QA tests).

Imagine that we do this:

 1 using System;
 2 
 3 namespace LeapYear
 4 {
 5     public class Year
 6     {
 7         private readonly int _aYear;
 8 
 9         public Year(int aYear)
10         {
11             _aYear = aYear;
12         }
13 
14         public bool? IsLeap()
15         {
16             if (_aYear % 4 == 0)
17             {
18                 return true;
19             }
20             
21             return false;
22         }
23     }
24 }

The existing tests will fail because we need to pass a parameter to the constructor, and also we don’t have any test that’s in charge of verifying the behavior that we’ve just implemented. We’d have to add tests to cover the functionality that we’ve introduced, but they’re no longer driving the development.

Second law: writing more that one test that fails

We can interpret this in two ways: writing multiple tests, or writing one test that involves too big a jump in behavior.

Writing multiple tests would cause several problems. To pass them all we would need to implement a large amount of code, and the guide that those tests could be providing gets so blurry that it’s almost like having none at all. We wouldn’t have clear and concrete indications to solve by implementing new code.

 1 using System;
 2 using System.Runtime.Remoting.Metadata.W3cXsd2001;
 3 using NUnit.Framework;
 4 
 5 namespace LeapYear
 6 {
 7     public class Tests
 8     {
 9         [Test]
10         public void CanInstantiate()
11         {
12             new Year();
13         }        
14         
15         [Test]
16         public void CanRespondToIsLeapMessage()
17         {
18             var year = new Year();
19             year.IsLeap();
20         }
21 
22         [Test]
23         public void CommonYearsShouldNotBeLeap()
24         {
25             var year = new Year(1997);
26             Assert.False(year.IsLeap());
27         }
28         
29         [Test]
30         public void YearDivisibleBy4ShouldBeLeap()
31         {
32             var year = new Year(1996);
33             Assert.True(year.IsLeap());
34         }
35     }
36 }

Here we’ve added two tests. To make them pass we’d have to define two behaviors. Also, they’re too large. We haven’t yet established, for example, that we’ll have to pass a parameter to the constructor, nor that the response will be of type bool. These tests mix various responsibilities and try to test too many things at once. We’d have too write too much production code in only one go, leading to insecurity and room for errors to occur.

Instead, we need to make tests for smaller increments of functionality. We can see several possibilities:

To introduce that the answer is a bool we can assume that, by default, the years aren’t leap years, so we’ll expect a false response:

 1 using System;
 2 using System.Runtime.Remoting.Metadata.W3cXsd2001;
 3 using NUnit.Framework;
 4 
 5 namespace LeapYear
 6 {
 7     public class Tests
 8     {
 9         [Test]
10         public void CanInstantiate()
11         {
12             new Year();
13         }        
14         
15         [Test]
16         public void CanRespondToIsLeapMessage()
17         {
18             var year = new Year();
19             year.IsLeap();
20         }
21 
22         [Test]
23         public void ByDefaultYearsAreNotLeapYears()
24         {
25             var year = new Year();
26             Assert.False(year.IsLeap());
27         }
28     }
29 }

The error is:

1 Argument 1: cannot convert from 'void' to 'bool?'

Can be solved with:

 1 using System;
 2 
 3 namespace LeapYear
 4 {
 5     public class Year
 6     {
 7         public Year()
 8         {
 9 
10         }
11 
12         public bool IsLeap()
13         {
14             return false;
15         }
16     }
17 }

However, we have another way to do it. Since the language is strongly typed, we can use the type system as a test. Thus, instead of creating a new test:

 1 using System;
 2 using System.Runtime.Remoting.Metadata.W3cXsd2001;
 3 using NUnit.Framework;
 4 
 5 namespace LeapYear
 6 {
 7     public class Tests
 8     {
 9         [Test]
10         public void CanInstantiate()
11         {
12             new Year();
13         }        
14         
15         [Test]
16         public void CanRespondToIsLeapMessage()
17         {
18             var year = new Year();
19             year.IsLeap();
20         }
21     }
22 }

We change the return type of IsLeap:

 1 using System;
 2 
 3 namespace LeapYear
 4 {
 5     public class Year
 6     {
 7         public Year()
 8         {
 9 
10         }
11 
12         public bool IsLeap()
13         {
14             
15         }
16     }
17 }

When we run the test it will indicate that there’s a problem, as the function isn’t returning anything:

1 'Year.IsLeap()': not all code paths return a value

And finally, we just have to add a default response, which will be false:

 1 using System;
 2 
 3 namespace LeapYear
 4 {
 5     public class Year
 6     {
 7         public Year()
 8         {
 9 
10         }
11 
12         public bool IsLeap()
13         {
14             return false;
15         }
16     }
17 }

To introduce the construction parameter we could use a refactoring. In this step we could be conditioned by the programming language, leading us to different solutions.

The refactoring path is straightforward. We just have to incorporate the parameter, although we won’t use it for now. In C# and other languages we could do it by introducing an alternative constructor, and in this way the tests would continue to pass. In other languages, we could mark the parameter as optional.

 1 using System;
 2 
 3 namespace LeapYear
 4 {
 5     public class Year
 6     {
 7         private readonly int _aYear;
 8 
 9         public Year()
10         {
11             
12         }
13 
14         public Year(int aYear)
15         {
16             _aYear = aYear;
17         }
18         
19         public bool IsLeap()
20         {
21             return false;
22         }
23     }
24 }

Since a parameterless constructor doesn’t make sense for us, now we could remove it, but first we’d have to refactor the tests so that they use the version with a parameter:

 1 using System;
 2 using System.Runtime.Remoting.Metadata.W3cXsd2001;
 3 using NUnit.Framework;
 4 
 5 namespace LeapYear
 6 {
 7     public class Tests
 8     {
 9         [Test]
10         public void CanInstantiate()
11         {
12             new Year(1997);
13         }        
14         
15         [Test]
16         public void CanRespondToIsLeapMessage()
17         {
18             var year = new Year(1997);
19             year.IsLeap();
20         }
21     }
22 }

The truth is that we don’t need the first test anymore, since it’s implicit in the other one.

 1 using System;
 2 using System.Runtime.Remoting.Metadata.W3cXsd2001;
 3 using NUnit.Framework;
 4 
 5 namespace LeapYear
 6 {
 7     public class Tests
 8     {
 9         [Test]
10         public void CanRespondToIsLeapMessage()
11         {
12             var year = new Year(1997);
13             year.IsLeap();
14         }
15 
16     }
17 }

And now we can remove the parameterless constructor, as it won’t be used again in any case:

 1 using System;
 2 
 3 namespace LeapYear
 4 {
 5     public class Year
 6     {
 7         private readonly int _aYear;
 8 
 9         public Year(int aYear)
10         {
11             _aYear = aYear;
12         }
13         
14         public bool IsLeap()
15         {
16             return false;
17         }
18     }
19 }

Third law: writing more production code than necessary to pass the test

This one is probably the most common violation of the three. We often come to a point where we “see” the algorithm so clearly that we feel tempted to write it now and finish the process for good. However, this can lead us to miss some situations. For example, we could “see” the general algorithm of an application and implement it. But, this could have distracted us and prevented us from considering one or several particular cases. This possibly incomplete algorithm, once incorporated to the application and deployed, could lead us to errors in production and even to economic losses.

For example, if we add a test to check that we control non-leap years:

 1 using System;
 2 using System.Runtime.Remoting.Metadata.W3cXsd2001;
 3 using NUnit.Framework;
 4 
 5 namespace LeapYear
 6 {
 7     public class Tests
 8     {
 9         [Test]
10         public void CanRespondToIsLeapMessage()
11         {
12             var year = new Year(1997);
13             year.IsLeap();
14         }
15 
16         [Test]
17         public void CommonYearsAreNoLeapYears()
18         {
19             var year = new Year(1997);
20             Assert.False(year.IsLeap());
21         }
22     }
23 }

In the current state of our exercise, an example of excess of code would be this:

 1 using System;
 2 
 3 namespace LeapYear
 4 {
 5     public class Year
 6     {
 7         private readonly int _aYear;
 8 
 9         public Year(int aYear)
10         {
11             _aYear = aYear;
12         }
13         
14         public bool IsLeap()
15         {
16             if (_aYear % 4 == 0)
17             {
18                 if (_aYear % 400 == 0)
19                 {
20                     return false;
21                 }
22 
23                 if (_aYear % 100 == 0)
24                 {
25                     return true;
26                 }
27 
28                 return true;
29             }
30             return false;
31         }
32     }
33 }

This code passes the test, but as you can see, we’ve introduced much more than it was necessary to achieve the behavior defined by the test, adding code to control leap years and special cases. So, apparently, everything is fine.

If we try a leap year we’ll see that the code works, which reinforces our impression that all’s good.

 1 using System;
 2 using System.Runtime.Remoting.Metadata.W3cXsd2001;
 3 using NUnit.Framework;
 4 
 5 namespace LeapYear
 6 {
 7     public class Tests
 8     {
 9         [Test]
10         public void CanRespondToIsLeapMessage()
11         {
12             var year = new Year(1997);
13             year.IsLeap();
14         }
15 
16         [Test]
17         public void CommonYearsAreNoLeapYears()
18         {
19             var year = new Year(1997);
20             Assert.False(year.IsLeap());
21         }
22 
23         [Test]
24         public void ShouldIdentifyStandardLeapYears()
25         {
26             var year = new Year(1996);
27             Assert.True(year.IsLeap());
28         }
29     }
30 }

But, a new test fails. Years divisible by 100 should not be leap years (unless they are also divisible by 400), and this error has been in our program for a while, but until now we didn’t have any test that executed that part of the code.

 1 using System;
 2 using System.Runtime.Remoting.Metadata.W3cXsd2001;
 3 using NUnit.Framework;
 4 
 5 namespace LeapYear
 6 {
 7     public class Tests
 8     {
 9         [Test]
10         public void CanRespondToIsLeapMessage()
11         {
12             var year = new Year(1997);
13             year.IsLeap();
14         }
15 
16         [Test]
17         public void CommonYearsAreNoLeapYears()
18         {
19             var year = new Year(1997);
20             Assert.False(year.IsLeap());
21         }
22 
23         [Test]
24         public void ShouldIdentifyStandardLeapYears()
25         {
26             var year = new Year(1996);
27             Assert.True(year.IsLeap());
28         }
29         
30         [Test]
31         public void ShouldIdentifyCenturyExceptionOfLeapYears()
32         {
33             var year = new Year(1900);
34             Assert.False(year.IsLeap());
35         }
36     }
37 }

This is the kind of problem that can go unnoticed when we add too much code at once in order to pass a test. The code excess probably doesn’t affect the test that we were working on, so we won’t know if it hides any kind of problem, and we won’t know it unless we happen to build a test that makes it surface. Or even worse, we won’t know it until the bug explodes in production.

The solution is pretty simple: only add the code that’s strictly necessary to pass the test, even if it’s just returning the value expected by the test itself. Don’t add any behavior if there’s not a failing test forcing you to do it.

In our case, it was the test which verified the handling of the non-leap years. In fact, the next test, which aimed to introduce the detection of standard leap years (years divisible by 4), passed without the need for adding any new code. This leads us to the next point.

What does it mean if a test passes just after writing it?

When we write a test and it passes without us needing to add any production code, it can be due to any of these reasons:

• The algorithm that we’ve written is general enough to cover all of the possible cases: we’ve completed the development.
• The example that we’ve chosen isn’t qualitatively different from others that we had already used, and therefore it’s not forcing us to write production code. We have to find a different example.
• We’ve added too much code, which is what we’ve just talked about in the previous bit.

In this leap year kata, for example, we’ll arrive at a point in which there’s no way of writing a test that fails because the algorithm supports all possible cases: regular non-leap years, leap years, non-leap years every 100 years, and leap years every 400.

The other possibility is that the chosen example doesn’t really represent a new behavior, which can be a symptom of a bad definition of the task, or of not having properly analyzed the possible scenarios.

The red-green-refactor cycle

The three laws establish a framework which we could call a “low level” one. Martin Fowler, for his part, defines the TDD cycle in these three phases which would be at a higher level of abstraction:

• Write a test for the next piece of functionality that you wish to add.
• Write the production code necessary to make the test pass.
• Refactor the code, both the new and the old, so that all’s well structured.

These three stages define what’s usually known as the “red-green-refactor” cycle, named like this in relation to the state of the tests in each of the phases of the cycle:

• Red: the creation of a failing test (it’s red) that describes the functionality or behavior that we want to introduce in the production software.
• Green: the writing of the necessary production code to pass the test (making it green), with which it’s verified that the specified behavior has been added.
• Refactor: while keeping the tests green, reorganizing the code in order to improve its structure, making it more readable and sustainable without losing the functionality that we’ve developed up until this point.

In practice, refactoring cycles only arise after a certain number of cycles of the three laws. The small changes driven by these start to accumulate, until they arrive at a point in which code smells start to appear, and with them the need for refactoring.

References

• The three rules of TDD¹
• The three rules of TDD - video²
• Refactoring the three laws of TDD³
• TDD with PHPSpec⁴
• The 3 Laws of TDD: Focus on One Thing at a Time⁵
• Test Driven Development⁶
• The cycles of TDD⁷

Fizz Buzz

Understanding the laws and cycles of TDD

The FizzBuzz kata is one of the easiest kata to start practicing TDD. It poses a very simple and well-defined problem, so, in a first phase it’s very easy to solve it completely in a session of one or two hours. But, its requirements can also be expanded. Setting the requisite that the size of the list should be configurable, that new rules can be added, etc., should bump up the difficulty a bit and lead us to achieve more complex developments.

In this case, being our first kata, we’ll follow the simplest version.

History

According to Coding Dojo, the authorship of the kata is unknown¹, but it’s commontly considered that it was introduced to society by Michael Feathers and Emily Bache in 2008, in the framework of the Agile2008 conference.

Problem statement

FizzBuzz is a game related to learning division in which a group of students take turns to count incrementally, saying a number each one, replacing any number divisible by three with the word “Fizz”, and any number divisible by five with the word “Buzz”. If the number is divisible by both three and five, then they say “FizzBuzz”.

So, our objective shall be to write a program that prints the numbers from 1 to 100 in such a way that:

• if the number is divisible by 3 it returns Fizz.
• if the number is divisible by 5 it returns Buzz.
• if the number is divisible by 3 and 5 it returns FizzBuzz.

Hints to solve it

The FizzBuzz kata is going to help us understard and start applying the Red-Green-Refactor cycle and the Three laws of TDD.

The first thing we should do is to consider the problem and get a general idea about how we’re going to solve it. TDD is a strategy that helps us avoid the necessity of having to make a detailed analysis and an exhaustive design prior to the solution, but that doesn’t mean that we shouldn’t first understand the problem and consider how we’re going to tackle it.

This is also necessary to avoid getting carried away by the literal statement of the kata, which can lead us to dead ends.

The first thing we’re going to do, once we have that general idea on how to approach the objective, is to apply the first law and write a test that fails.

This test should define the first behavior that we need to implement.

Writing a test that fails means, at this time, writing a test that won’t work because there isn’t any code to run, a fact that will be pointed out to us by the error messages. Even though you might find it absurd, you must try to run the test and confirm that it doesn’t pass. It’s the test error messages that will tell you what to do next.

To get the test to fail we have to apply the second law, which says that we can’t write more tests than necessary to fail. The smallest possible test should force us to define the class by instantiating it, and little more.

Last, to make the test pass, we’ll apply the third law, which says that we mustn’t write any more production code than necessary to pass the test. That is: define the class, the method that we’re going to exercise (if applicable), and make it return some response that will finally make the test pass.

The two first steps of this stage are pretty obvious, but the third one, not so much.

With the first two steps we try to make the test fail for the right reasons. That is, first it fails because we haven’t written the class, so we define it. Then, it will fail because the method that we’re calling is missing, so we define it as well. Finally, it will fail because it doesn’t return the response that we expect, which is what we’re testing in itself.

And what response should we be returning? Well, no more no less than the one that the test expects.

Once we have a first test and a first piece of production code that makes it pass, we’ll ask ourselves this question: what will be the next behavior that I should implement?

Links of interest about the FizzBuzz kata

• Video of the kata by Jesús López de la Cruz²
• FizzBuzz in Kata-log³
• Solved FizzBuzz in SmallTalk⁴
• Code Katas Explained: FizzBuzz⁵
• TDD — Which Order to Write Your Tests⁶
• Solution in Python using a use case list⁷

Solving the Fizz Buzz kata

Statement of the kata

Our objective will be to write a program that prints the numbers from 1 to 100 in such a way that:

• if the number is divisible by 3 it returns Fizz.
• if the number is divisible by 5 it returns Buzz.
• if the number is divisible by 3 and 5 it returns FizzBuzz.

Language and focus

We’re going to solve this kata in Python with unittest as our testing environment. The task consists in creating a FizzBuzz class which will have a generate method to create the list, so it will be used more or less like this:

1 fizzbuzz = Fizzbuzz()
2 print(fizzbuzz.generate())

To do so, I create a folder called fizzbuzzkata and to it I add the fizzbuzz_test.py file.

Define the class

What the exercise asks for is a list with the numbers from 1 to 100 changing some of them by the words “Fizz”, “Buzz”, or both of them in case of fulfilling certain condictions.

Note that it doesn’t ask for a list of any amount of numbers, but rather specifically from 1 to 100. We’ll come back to this in a moment.

Now we’re going to focus in that first test. The less we can do is make it possible to instantiate a FizzBuzz type object. Here’s a possible first test:

 1 import unittest
 2 
 3 
 4 class FizzBuzzTestCase(unittest.TestCase):
 5     def test_something(self):
 6         FizzBuzz()
 7 
 8 
 9 if __name__ == '__main__':
10     unittest.main()

It may look weird. This test is just limited to trying to instantiate the class and nothing else.

This first test should be enough to fail, which is what the second law states, and force us to define the class so the test can pass, fulfilling the third law. In some environments it would be necessary to add an assertion, given that they consider that the test hasn’t passed if it hasn’t been explicitly verified, but it’s not the case in Python.

So, we launch it to see if it really fails. The result, as it was expected, is that the test doesn’t pass, displaying the following error:

1 NameError: name 'FizzBuzz' is not defined

To pass the test we’ll have to define the FizzBuzz class, something we’ll do in the test file itself.

 1 import unittest
 2 
 3 class FizzBuzz(object):
 4     pass
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     def test_something(self):
 8         FizzBuzz()
 9 
10 
11 if __name__ == '__main__':
12     unittest.main()

And with this, the test will pass. Now that we’re green we can think about refactoring. The class doesn’t have any code, but we could change the name of the test for a more adequate one:

 1 import unittest
 2 
 3 class FizzBuzz:
 4     pass
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     def test_can_instantiate(self):
 8         FizzBuzz()
 9 
10 
11 if __name__ == '__main__':
12     unittest.main()

Usually it’s better that the classes live in their own file (or Python module) because it makes it easier to manage the code and keep everything located. So, we create a fizzbuzz.py file and we move the class to it.

And in the test, we import it:

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     def test_can_instantiate(self):
 8         FizzBuzz()
 9 
10 
11 if __name__ == '__main__':
12     unittest.main()

When we introduce this change and run the test, we can verify that it passes and that we’re in green.

We’ve fulfilled the three laws and closed our first test-code-refactor cycle. There’s not much else to do here, except for moving on to the next test.

Define the generate method

The FizzBuzz class not only doesn’t do anything, it doesn’t even have any methods! We’ve said that we want it to have a generate method, which is the one that will return the list of numbers from 1 to 100.

To force us to write the generate method, we have to write a test that calls it. The method will have to return something, right? No, not really. It’s not always necessary to return something. It’s enough if nothing breaks when we call it.

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     def test_can_instantiate(self):
 8         FizzBuzz()
 9 
10     def test_responds_to_generate_message(self):
11         fizzbuzz = FizzBuzz()
12         fizzbuzz.generate()
13 
14 
15 if __name__ == '__main__':
16     unittest.main()

When we run the test, it tells us that the object doesn’t have any generate method:

1 AttributeError: 'FizzBuzz' object has no attribute 'generate'

Of course it doesn’t, we have to add it:

1 class FizzBuzz(object):
2     def generate(self):
3         pass

Now we already have a class capable of answering to the generate message. Can we do any refactoring here?

Well, yes, but not in the production code, but in the tests. It turns out that the test that we’ve just written overlaps the previous one. That is, the test_responds_to_generate_message test covers the test_can_instantiate test, making it redundant. Therefore, we can remove it:

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     def test_responds_to_generate_message(self):
 8         fizzbuzz = FizzBuzz()
 9         fizzbuzz.generate()
10 
11 
12 if __name__ == '__main__':
13     unittest.main()

Perhaps this surprises you. This is what we talk about in the beginning of the book, some of the tests that we use to drive the development stop being useful for some reason or another. Generally, they end up becoming redundant and don’t provide any information that we’re not already getting from other tests.

Define a behavior for generate

Specifically, we want it to return a list of numbers. But it doesn’t need to have the multiples of 3 and 5 converted just yet.

The test should verify this, but it must keep passing when we have developed the complete algorithm. What we could verify would be that it returns a 100 element list, without paying any attention to what it contains exactly.

This test will force us to give it a behavior in response to the generate message:

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7 
 8     def test_respond_to_generate_message(self):
 9         fizzbuzz = FizzBuzz()
10         fizzbuzz.generate()
11 
12     def test_generates_list_of_100_elements(self):
13         fizzbuzz = FizzBuzz()
14         num_list = fizzbuzz.generate()
15         self.assertEqual(100, len(num_list))
16 
17 
18 if __name__ == '__main__':
19     unittest.main()

Of course, the test fails:

1 TypeError: object of type 'NoneType' has no len()

Right now, the method returns None. We want a list:

1 class FizzBuzz(object):
2     def generate(self):
3         return []

When we change generate so that it returns a list, the test fails because our condition isn’t met: that the list has a certain number of elements.

1 AssertionError: 100 != 0

This one is finally an error from the test. The previous one were basically equivalent to compiling errors (syntax errors, etc.). That’s why it’s so important to see the tests fail, to use the feedback that the error messages provide us.

Making the test pass is quite easy:

1 class FizzBuzz(object):
2     def generate(self):
3         return [None] * 100

With the test in green, let’s think a little.

In the first place, it could be argued that in this test we’ve asked generate to return a response that meets two conditions:

• be of type list (or array, or collection)
• have exactly 100 elements

We could have forced this same thing with two even smaller tests.

This tiny little steps are often called baby steps, and the truth is that they don’t have a fixed length, they depend on our practice and experience instead.

Thus, for example, the test that we’ve created is small enough to not generate a big leap in the production code, although it’s capable of verifying both conditions at once.

In the second place, note that we’ve just written the necessary code to fulfill the test. In fact, we return a list of 100 None elements, which may seem a little pointless, but it’s enough to achieve this test’s objective. Remember: don’t write more code than necessary to pass the test.

In the third place, we have written enough code, between test and production, to be able to examine it and see if there’s any opportunity for refactoring.

The clearest refactoring opportunity that we have right now is the magic number 100, which we could store in a class variable. Again, each language will have its own options:

1 class FizzBuzz(object):
2     _NUMBER_OF_ELEMENTS = 100
3 
4     def generate(self):
5         return [None] * self._NUMBER_OF_ELEMENTS

And we have some more in the test code. Once again, the new test that we’ve added overlaps and includes the old one, which we could remove.

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7 
 8     def test_generates_list_of_100_elements(self):
 9         fizzbuzz = FizzBuzz()
10         num_list = fizzbuzz.generate()
11         self.assertEqual(100, len(num_list))
12 
13 
14 if __name__ == '__main__':
15     unittest.main()

In the same way, the name of the test could improve. Instead of referencing the specific number, we could simply indicate something more general, that doesn’t tie the test to a specific implementation detail.

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7 
 8     def test_generates_list_of_required_number_of_elements(self):
 9         fizzbuzz = FizzBuzz()
10         num_list = fizzbuzz.generate()
11         self.assertEqual(100, len(num_list))
12 
13 
14 if __name__ == '__main__':
15     unittest.main()

Last but not least, we still have a magic number 100, which we will name:

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     _NUMBER_OF_ELEMENTS = 100
 8 
 9     def test_generates_list_of_required_number_of_elements(self):
10         fizzbuzz = FizzBuzz()
11         num_list = fizzbuzz.generate()
12         self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))
13 
14 
15 if __name__ == '__main__':
16     unittest.main()

And with this, we’ll have finished a new cycle in which we have already introduced the refactoring phase.

Generate a list of numbers

Our FizzBuzz can already generate a list with 100 elements, but at the moment each of them is literally nothing. It’s time to write a test that forces us to put some elements inside that list.

To do this, we could expect the generated list to contain the numbers from 1 to 100. However, we have a problem: at the end of the development process, the list wil contain the numbers but some of them will be represented by the words Fizz, Buzz, or FizzBuzz. If I don’t take this into account, this third test will start failing as soon as I start implementing the algorithm that converts the numbers. It doesn’t seem like a good solution.

A more promising approach would be: what numbers won’t be affected by the algorithm? Well, those that aren’t multiples of 3 or 5. Thereby, we could choose some of them to verify that they’re included in the untransformed list.

The simplest of them all is 1, which should occupy the first position of the list. For symmetry reasons we’re going to generate the numbers as strings.

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     _NUMBER_OF_ELEMENTS = 100
 8 
 9     def test_generates_list_of_required_number_of_elements(self):
10         fizzbuzz = FizzBuzz()
11         num_list = fizzbuzz.generate()
12         self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))
13 
14     def test_number_one_is_represented_as_itself(self):
15         fizzbuzz = FizzBuzz()
16         num_list = fizzbuzz.generate()
17         self.assertEqual('1', num_list[0])
18 
19 
20 if __name__ == '__main__':
21     unittest.main()

The test is very small and fails:

1 None != 1

At this point, what change could we introduce in the production code to make the test pass? The most obvious one could be the following:

1 class FizzBuzz(object):
2     _NUMBER_OF_ELEMENTS = 100
3 
4     def generate(self):
5         return ['1'] * self._NUMBER_OF_ELEMENTS

It’s enough to pass the test, so it suits us.

One problem that we have here is that the number ‘1’ doesn’t appear as such in the test. What it does appear is its representation, but we use its position in num_list, which is a 0-index array. We’re going to make explicit the fact that we’re testing against the representation of a number. First, we introduce the concept of position:

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     _NUMBER_OF_ELEMENTS = 100
 8 
 9     def test_generates_list_of_required_number_of_elements(self):
10         fizzbuzz = FizzBuzz()
11         num_list = fizzbuzz.generate()
12         self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))
13 
14     def test_number_one_is_represented_as_itself(self):
15         fizzbuzz = FizzBuzz()
16         num_list = fizzbuzz.generate()
17         position = 0
18         self.assertEqual('1', num_list[position])
19 
20 
21 if __name__ == '__main__':
22     unittest.main()

And now the concept of number, as well as its relationship with position:

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     _NUMBER_OF_ELEMENTS = 100
 8 
 9     def test_generates_list_of_required_number_of_elements(self):
10         fizzbuzz = FizzBuzz()
11         num_list = fizzbuzz.generate()
12         self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))
13 
14     def test_number_one_is_represented_as_itself(self):
15         fizzbuzz = FizzBuzz()
16         num_list = fizzbuzz.generate()
17         number = 1
18         position = number - 1
19         self.assertEqual('1', num_list[position])
20 
21 
22 if __name__ == '__main__':
23     unittest.main()

Now we don’t need to refer to the position at all, just to the number.

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     _NUMBER_OF_ELEMENTS = 100
 8 
 9     def test_generates_list_of_required_number_of_elements(self):
10         fizzbuzz = FizzBuzz()
11         num_list = fizzbuzz.generate()
12         self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))
13 
14     def test_number_one_is_represented_as_itself(self):
15         fizzbuzz = FizzBuzz()
16         num_list = fizzbuzz.generate()
17         number = 1
18         self.assertEqual('1', num_list[(number - 1)])
19 
20 
21 if __name__ == '__main__':
22     unittest.main()

We could make the test easier to read. First, we separate the verification:

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     _NUMBER_OF_ELEMENTS = 100
 8 
 9     def test_generates_list_of_required_number_of_elements(self):
10         fizzbuzz = FizzBuzz()
11         num_list = fizzbuzz.generate()
12         self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))
13 
14     def test_number_one_is_represented_as_itself(self):
15         number = 1
16 
17         self.__assert_number_is_represented_as(number)
18 
19     def __assert_number_is_represented_as(self, number):
20         fizzbuzz = FizzBuzz()
21         num_list = fizzbuzz.generate()
22         self.assertEqual('1', num_list[(number - 1)])
23 
24 
25 if __name__ == '__main__':
26     unittest.main()

We extract the representation as a parameter in the assertion, and we make an inline of number, to make the reading more fluent:

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     _NUMBER_OF_ELEMENTS = 100
 8 
 9     def test_generates_list_of_required_number_of_elements(self):
10         fizzbuzz = FizzBuzz()
11         num_list = fizzbuzz.generate()
12         self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))
13 
14     def test_number_one_is_represented_as_itself(self):
15         self.__assert_number_is_represented_as(1, '1')
16 
17     def __assert_number_is_represented_as(self, number, representation):
18         fizzbuzz = FizzBuzz()
19         num_list = fizzbuzz.generate()
20         self.assertEqual(representation, num_list[(number - 1)])
21 
22 
23 if __name__ == '__main__':
24     unittest.main()

As you can see, we’ve work a lot in the test. Now introducing new examples will be very inexpensive, which will help us write more tests and make the process more pleasant and convenient.

We keep generating numbers

Actually, we haven’t yet verified whether the generate method is returning a list of numbers, so we need to keep writing new tests that force us to create that code.

Let’s make sure that the second position is occupied by the number two, which is the next simplest number that’s not a multiple of 3 or 5.

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     _NUMBER_OF_ELEMENTS = 100
 8 
 9     def test_generates_list_of_required_number_of_elements(self):
10         fizzbuzz = FizzBuzz()
11         num_list = fizzbuzz.generate()
12         self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))
13 
14     def test_number_one_is_represented_as_itself(self):
15         self.__assert_number_is_represented_as(1, '1')
16         self.__assert_number_is_represented_as(2, '2')
17 
18     def __assert_number_is_represented_as(self, number, representation):
19         fizzbuzz = FizzBuzz()
20         num_list = fizzbuzz.generate()
21         self.assertEqual(representation, num_list[(number - 1)])
22 
23 
24 if __name__ == '__main__':
25     unittest.main()

We have a new test which fails, so we’re going to add some code to production so that the tets passes.
However, we have some problems with this implementation:

1 class FizzBuzz(object):
2     _NUMBER_OF_ELEMENTS = 100
3 
4     def generate(self):
5         return ['1'] * self._NUMBER_OF_ELEMENTS

To intervene in it, we’d need to refactor it a little first. At least, extract the response to a variable that we could manipulate before returning it.

But, since the test is failing right now, we can’t refactor. Before that we have to cancel or delete the test that we’ve just created. The easiest would be to comment it out to prevent its execution. Remember, to do any refactorings it’s compulsory that the tests are passing:

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     _NUMBER_OF_ELEMENTS = 100
 8 
 9     def test_generates_list_of_required_number_of_elements(self):
10         fizzbuzz = FizzBuzz()
11         num_list = fizzbuzz.generate()
12         self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))
13 
14     def test_number_one_is_represented_as_itself(self):
15         self.__assert_number_is_represented_as(1, '1')
16         # self.__assert_number_is_represented_as(2, '2')
17 
18     def __assert_number_is_represented_as(self, number, representation):
19         fizzbuzz = FizzBuzz()
20         num_list = fizzbuzz.generate()
21         self.assertEqual(representation, num_list[(number - 1)])
22 
23 
24 if __name__ == '__main__':
25     unittest.main()

Now we can work:

1 class FizzBuzz(object):
2     _NUMBER_OF_ELEMENTS = 100
3 
4     def generate(self):
5         num_list = ['1'] * self._NUMBER_OF_ELEMENTS
6         return num_list

And we activate the test again, which now fails because the number 2 is represented by a ‘1’. The simplest change that I can come up with, right now, is this one. So silly:

1 class FizzBuzz(object):
2     _NUMBER_OF_ELEMENTS = 100
3 
4     def generate(self):
5         num_list = ['1'] * self._NUMBER_OF_ELEMENTS
6         num_list[1] = '2'
7         
8         return num_list

The truth is that the test is green. We know that this is not the implementation that will solve the full problem, but our production code is only obligated to satisfy the existing tests and nothing more. So, let’s not get ahead of ourselves. Let’s see what we can do.

To start, the name of the test is obsolete, let’s generalize it:

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     _NUMBER_OF_ELEMENTS = 100
 8 
 9     def test_generates_list_of_required_number_of_elements(self):
10         fizzbuzz = FizzBuzz()
11         num_list = fizzbuzz.generate()
12         self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))
13 
14     def test_number_is_represented_as_itself(self):
15         self.__assert_number_is_represented_as(1, '1')
16         self.__assert_number_is_represented_as(2, '2')
17 
18     def __assert_number_is_represented_as(self, number, representation):
19         fizzbuzz = FizzBuzz()
20         num_list = fizzbuzz.generate()
21         self.assertEqual(representation, num_list[(number - 1)])
22 
23 
24 if __name__ == '__main__':
25     unittest.main()

Now that this has been solved, let’s remember that previously we saw that the concepts of “number” and “representation” were necessary to better define the expected behavior in the tests. We can now introduce them in our production code:

 1 class FizzBuzz(object):
 2     _NUMBER_OF_ELEMENTS = 100
 3 
 4     def generate(self):
 5         num_list = ['1'] * self._NUMBER_OF_ELEMENTS
 6         
 7         number = 2
 8         representation = '2'
 9         
10         num_list[number-1] = representation
11 
12         return num_list

It’s a first step. We can see the limitations of the current solution. For example, why does the 1 have a special treatment? And what will happen if we want to verify other number? There are several problems.

As for the number 1, the key lies in the list of numbers idea. Right now we’re generating a list of constants, but each of the elements of the list should be a correlative number, beginning with 1 until completing the desired number of elements.

And then we’d have to replace each number by its representation. Something like this:

 1 class FizzBuzz(object):
 2     _NUMBER_OF_ELEMENTS = 100
 3 
 4     def generate(self):
 5         num_list = list(range(1, self._NUMBER_OF_ELEMENTS + 1))
 6 
 7         number = 1
 8         representation = '1'
 9 
10         num_list[number-1] = representation
11 
12         number = 2
13         representation = '2'
14 
15         num_list[number-1] = representation
16 
17         return num_list

This structure keeps passing the test, but it doesn’t seem very practical. However, we can see a pattern. We need to iterate over the list to give solution:

 1 class FizzBuzz(object):
 2     _NUMBER_OF_ELEMENTS = 100
 3 
 4     def generate(self):
 5         num_list = list(range(1, self._NUMBER_OF_ELEMENTS + 1))
 6         for number in num_list:
 7             if number == 1:
 8                 representation = '1'
 9 
10             if number == 2:
11                 representation = '2'
12 
13             num_list[number-1] = representation
14 
15         return num_list

With the information that we have, we could simply assume that it’s enough to convert the number into a string and put it in its place:

 1 class FizzBuzz(object):
 2     _NUMBER_OF_ELEMENTS = 100
 3 
 4     def generate(self):
 5         num_list = list(range(1, self._NUMBER_OF_ELEMENTS + 1))
 6         for number in num_list:
 7             representation = str(number)
 8             num_list[number-1] = representation
 9 
10         return num_list

Of course, there are more compact and pythonic ways, such as this one:

1 class FizzBuzz:
2 
3     _NUMBERS_IN_LIST = 100
4     
5     def generate(self):
6         return list(map(lambda num: str(num + 1), range(self._NUMBERS_IN_LIST)))

But we should be careful, we’re probably getting too ahead of ourselves with this refactoring, and it’ll surely become a source of problems further down the line. For this reason, it’s preferable to keep a more direct and naive implementation, and leave the optimizations and more advanced structures for later, when the behavior of the method is completely defined. So, I would advise you to avoid this kind of approach.

All of this refactoring is done while the tests are green. This means that:

1. With the test, we describe the behavior that we want to develop
2. We make the test pass by writing the simplest possible code, as stupidly simple it looks, with the intent of implementing that behavior
3. We use the green tests as a safety net to restructure the code until we find a better design: easy to understand, maintain, and extend.

Points 2 and 3 are build based on these principles:

• KISS: Keep it simply stupid, which means keeping the system as mindless as possible, that is, not trying to add intelligence prematurely. The more mechanical and simple, the better, as long as it meets its needs. This KISS is our first approach.
• Gall’s law: every working complex system has evolved from a simpler system that also worked. Therefore, we start with a very simple implementation that works (KISS), and we make it evolve towards a more complex one that works as well, something that we’re sure about because the test keeps passing.
• YAGNI: You aren’t gonna need it, which prevents us from implementing more code than strictly necessary to pass the current tests.

But now we have to implement new behaviors.

The test that doesn’t fail

The next number which is not a multiple of 3, 5 o 15 is 4, so we add an example for this:

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     _NUMBER_OF_ELEMENTS = 100
 8 
 9     def test_generates_list_of_required_number_of_elements(self):
10         fizzbuzz = FizzBuzz()
11         num_list = fizzbuzz.generate()
12         self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))
13 
14     def test_number_is_represented_as_itself(self):
15         self.__assert_number_is_represented_as(1, '1')
16         self.__assert_number_is_represented_as(2, '2')
17         self.__assert_number_is_represented_as(4, '4')
18 
19     def __assert_number_is_represented_as(self, number, representation):
20         fizzbuzz = FizzBuzz()
21         num_list = fizzbuzz.generate()
22         self.assertEqual(representation, num_list[(number - 1)])
23 
24 
25 if __name__ == '__main__':
26     unittest.main()

And the test passes. Good news? It depends. A test that passes just after its creation is always a reason for suspicion, at least from a TDD point of view. Remember: writing a failing test is always the first thing to do. If the test doesn’t fail, it means that:

• The behavior is already implemented
• It’s not the test we were looking for

In our case, the last refactoring has resulted in the general behavior of the numbers that don’t need transformation. In fact, we can categorize the numbers in these classes:

• Numbers that are represented as themselves
• Multiples of three, represented as ‘Fizz’
• Multiples of five, represented as ‘Buzz’
• Multiples of both three and five, represented as ‘FizzBuzz’

Numbers 1 and 2 belong to the first class, so they’re more than enough, since any of the numbers in that class would serve as an example. In TDD we need them both, because they’ve helped us to introduce the idea that we would have to iterate through the number list. However, just one of them would be sufficient for a QA test. For this reason, when we introduce the example of the number 4, we don’t have to add any additional code: the behavior is already implemented.

It’s time to move on to the other classes of numbers.

Learning to say “Fizz”

It’s time for our FizzBuzz to be able to convert the 3 into “Fizz”. A minimal test to specify this would be the following:

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     _NUMBER_OF_ELEMENTS = 100
 8 
 9     def test_generates_list_of_required_number_of_elements(self):
10         fizzbuzz = FizzBuzz()
11         num_list = fizzbuzz.generate()
12         self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))
13 
14     def test_number_is_represented_as_itself(self):
15         self.__assert_number_is_represented_as(1, '1')
16         self.__assert_number_is_represented_as(2, '2')
17         self.__assert_number_is_represented_as(4, '4')
18 
19     def test_three_and_its_multiples_are_represented_as_fizz(self):
20         self.__assert_number_is_represented_as(3, 'Fizz')
21 
22 
23     def __assert_number_is_represented_as(self, number, representation):
24         fizzbuzz = FizzBuzz()
25         num_list = fizzbuzz.generate()
26         self.assertEqual(representation, num_list[(number - 1)])
27 
28 
29 if __name__ == '__main__':
30     unittest.main()

Having a failing test, let’s see what minimal production code we could add to pass it:

 1 class FizzBuzz(object):
 2     _NUMBER_OF_ELEMENTS = 100
 3 
 4     def generate(self):
 5         num_list = list(range(1, self._NUMBER_OF_ELEMENTS + 1))
 6         for number in num_list:
 7             representation = str(number)
 8 
 9             if number == 3:
10                 representation = 'Fizz'
11 
12             num_list[number - 1] = representation
13 
14         return num_list

We’ve added an if that makes this particular case pass. For the time being, with the information that we have, there isn’t any other better way. Remember KISS, Gall and YAGNI to avoid advancing faster than you should.

Regarding the code, there may be a better way to populate the list. Instead of generating a list of numbers and changing it later, perhaps we could initialize an empty list and append the representations of the numbers one by one.

 1 class FizzBuzz(object):
 2     _NUMBER_OF_ELEMENTS = 100
 3 
 4     def generate(self):
 5         representations = list()
 6         num_list = list(range(1, self._NUMBER_OF_ELEMENTS + 1))
 7         for number in num_list:
 8             representation = str(number)
 9 
10             if number == 3:
11                 representation = 'Fizz'
12 
13             representations.append(representation)
14 
15         return representations

This works. Now num_list becomes kind of pointless as a list. We can make a change:

 1 class FizzBuzz(object):
 2     _NUMBER_OF_ELEMENTS = 100
 3 
 4     def generate(self):
 5         representations = list()
 6         num_list = range(1, self._NUMBER_OF_ELEMENTS + 1)
 7         for number in num_list:
 8             representation = str(number)
 9 
10             if number == 3:
11                 representation = 'Fizz'
12 
13             representations.append(representation)
14 
15         return representations

And remove the temporary variable:

 1 class FizzBuzz(object):
 2     _NUMBER_OF_ELEMENTS = 100
 3 
 4     def generate(self):
 5         representations = list()
 6         for number in range(1, self._NUMBER_OF_ELEMENTS + 1):
 7             representation = str(number)
 8 
 9             if number == 3:
10                 representation = 'Fizz'
11 
12             representations.append(representation)
13 
14         return representations

Everything continues to work correctly, as the tests attest.

Saying “Fizz” at the right time

Now we want it to add a “Fizz” when the corresponding number is a multiple of 3, and not just when it’s exactly 3. Of course, we have to add a test to specify this. This time we use the number 6, which is the closest multiple of 3 (and not of 5) that we have.

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     _NUMBER_OF_ELEMENTS = 100
 8 
 9     def test_generates_list_of_required_number_of_elements(self):
10         fizzbuzz = FizzBuzz()
11         num_list = fizzbuzz.generate()
12         self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))
13 
14     def test_number_is_represented_as_itself(self):
15         self.__assert_number_is_represented_as(1, '1')
16         self.__assert_number_is_represented_as(2, '2')
17         self.__assert_number_is_represented_as(4, '4')
18 
19     def test_three_and_its_multiples_are_represented_as_fizz(self):
20         self.__assert_number_is_represented_as(3, 'Fizz')
21         self.__assert_number_is_represented_as(6, 'Fizz')
22 
23 
24     def __assert_number_is_represented_as(self, number, representation):
25         fizzbuzz = FizzBuzz()
26         num_list = fizzbuzz.generate()
27         self.assertEqual(representation, num_list[(number - 1)])
28 
29 
30 if __name__ == '__main__':
31     unittest.main()

To pass the test we just have to make a pretty small change. We have to modify the condition to expand it to all of the multiples of three. But we’re going to do it incrementally.

First, we establish the behavior:

 1 class FizzBuzz(object):
 2     _NUMBER_OF_ELEMENTS = 100
 3 
 4     def generate(self):
 5         representations = list()
 6         for number in range(1, self._NUMBER_OF_ELEMENTS + 1):
 7             representation = str(number)
 8 
 9             if number == 3:
10                 representation = 'Fizz'
11 
12             if number == 6:
13                 representation = 'Fizz'
14 
15             representations.append(representation)
16 
17         return representations

With this, the test passes. Now let’s change the code so that it uses the concept of multiple of:

 1 class FizzBuzz(object):
 2     _NUMBER_OF_ELEMENTS = 100
 3 
 4     def generate(self):
 5         representations = list()
 6         for number in range(1, self._NUMBER_OF_ELEMENTS + 1):
 7             representation = str(number)
 8 
 9             if number == 3:
10                 representation = 'Fizz'
11 
12             if number == 6:
13                 representation = 'Fizz'
14 
15             if number % 3 == 0:
16                 representation = 'Fizz'
17 
18             representations.append(representation)
19 
20         return representations

The test keeps passing, which indicates that our hypothesis is correct. Now we can remove the redundant part of the code:

 1 class FizzBuzz(object):
 2     _NUMBER_OF_ELEMENTS = 100
 3 
 4     def generate(self):
 5         representations = list()
 6         for number in range(1, self._NUMBER_OF_ELEMENTS + 1):
 7             representation = str(number)
 8 
 9             if number % 3 == 0:
10                 representation = 'Fizz'
11 
12             representations.append(representation)
13 
14         return representations

At this point you may want to try other examples from the same class, although it’s not really necessary since any multiple of three is an adequate representative. For this reason, we’ll move on to the next behavior.

Learning to say “Buzz”

This test lets us specify the new behavior:

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     _NUMBER_OF_ELEMENTS = 100
 8 
 9     def test_generates_list_of_required_number_of_elements(self):
10         fizzbuzz = FizzBuzz()
11         num_list = fizzbuzz.generate()
12         self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))
13 
14     def test_number_is_represented_as_itself(self):
15         self.__assert_number_is_represented_as(1, '1')
16         self.__assert_number_is_represented_as(2, '2')
17         self.__assert_number_is_represented_as(4, '4')
18 
19     def test_three_and_its_multiples_are_represented_as_fizz(self):
20         self.__assert_number_is_represented_as(3, 'Fizz')
21         self.__assert_number_is_represented_as(6, 'Fizz')
22 
23     def test_five_and_its_multiples_are_represented_as_buzz(self):
24         self.__assert_number_is_represented_as(5, 'Buzz')
25 
26     def __assert_number_is_represented_as(self, number, representation):
27         fizzbuzz = FizzBuzz()
28         num_list = fizzbuzz.generate()
29         self.assertEqual(representation, num_list[(number - 1)])
30 
31 
32 if __name__ == '__main__':
33     unittest.main()

So, we modify the production code to make the test pass. Same as we did before, we treat the particular case in a particular manner.

 1 class FizzBuzz(object):
 2     _NUMBER_OF_ELEMENTS = 100
 3 
 4     def generate(self):
 5         representations = list()
 6         for number in range(1, self._NUMBER_OF_ELEMENTS + 1):
 7             representation = str(number)
 8 
 9             if number % 3 == 0:
10                 representation = 'Fizz'
11 
12             if number == 5:
13                 representation = 'Buzz'
14 
15             representations.append(representation)
16 
17         return representations

Yes, we already know how we should handle the general case of the multiples of five, but it’s preferable to force ourselves to go slowly. Remember that the main objective of the exercise isn’t to solve the list generation, but rather do it guided by tests. Our main interest now is to internalize this slow step cycle.

There’s not much else that we can do now, except for continuing to the next test.

Saying “Buzz” at the right time

At this point, the test is quite obvious, the next multiple of 5 is 10:

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     _NUMBER_OF_ELEMENTS = 100
 8 
 9     def test_generates_list_of_required_number_of_elements(self):
10         fizzbuzz = FizzBuzz()
11         num_list = fizzbuzz.generate()
12         self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))
13 
14     def test_number_is_represented_as_itself(self):
15         self.__assert_number_is_represented_as(1, '1')
16         self.__assert_number_is_represented_as(2, '2')
17         self.__assert_number_is_represented_as(4, '4')
18 
19     def test_three_and_its_multiples_are_represented_as_fizz(self):
20         self.__assert_number_is_represented_as(3, 'Fizz')
21         self.__assert_number_is_represented_as(6, 'Fizz')
22 
23     def test_five_and_its_multiples_are_represented_as_buzz(self):
24         self.__assert_number_is_represented_as(5, 'Buzz')
25         self.__assert_number_is_represented_as(10, 'Buzz')
26 
27     def __assert_number_is_represented_as(self, number, representation):
28         fizzbuzz = FizzBuzz()
29         num_list = fizzbuzz.generate()
30         self.assertEqual(representation, num_list[(number - 1)])
31 
32 
33 if __name__ == '__main__':
34     unittest.main()

And, again, the change in the production code is simple at first:

 1 class FizzBuzz(object):
 2     _NUMBER_OF_ELEMENTS = 100
 3 
 4     def generate(self):
 5         representations = list()
 6         for number in range(1, self._NUMBER_OF_ELEMENTS + 1):
 7             representation = str(number)
 8 
 9             if number % 3 == 0:
10                 representation = 'Fizz'
11 
12             if number == 5:
13                 representation = 'Buzz'
14 
15             if number == 10:
16                 representation = 'Buzz'
17 
18             representations.append(representation)
19 
20         return representations

Next, we perform the refactoring step by step, now that we’ve ensured the behavior:

 1 class FizzBuzz(object):
 2     _NUMBER_OF_ELEMENTS = 100
 3 
 4     def generate(self):
 5         representations = list()
 6         for number in range(1, self._NUMBER_OF_ELEMENTS + 1):
 7             representation = str(number)
 8 
 9             if number % 3 == 0:
10                 representation = 'Fizz'
11 
12             if number == 5:
13                 representation = 'Buzz'
14 
15             if number == 10:
16                 representation = 'Buzz'
17                 
18             if number % 5 == 0:
19                 representation = 'Buzz'
20 
21             representations.append(representation)
22 
23         return representations

And then:

 1 class FizzBuzz(object):
 2     _NUMBER_OF_ELEMENTS = 100
 3 
 4     def generate(self):
 5         representations = list()
 6         for number in range(1, self._NUMBER_OF_ELEMENTS + 1):
 7             representation = str(number)
 8 
 9             if number % 3 == 0:
10                 representation = 'Fizz'
11 
12             if number % 5 == 0:
13                 representation = 'Buzz'
14 
15             representations.append(representation)
16 
17         return representations

And with this refactoring, we can proceed to the next -and last- class of numbers.

Learning to say “FizzBuzz”

The structure is exactly the same. Let’s start with the simplest case: 15 should return FizzBuzz, since 15 is the first number that is a multiple of 3 and 5 at the same time.

 1 import unittest
 2 
 3 from fizzbuzzkata.fizzbuzz import FizzBuzz
 4 
 5 
 6 class FizzBuzzTestCase(unittest.TestCase):
 7     _NUMBER_OF_ELEMENTS = 100
 8 
 9     def test_generates_list_of_required_number_of_elements(self):
10         fizzbuzz = FizzBuzz()
11         num_list = fizzbuzz.generate()
12         self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))
13 
14     def test_number_is_represented_as_itself(self):
15         self.__assert_number_is_represented_as(1, '1')
16         self.__assert_number_is_represented_as(2, '2')
17         self.__assert_number_is_represented_as(4, '4')
18 
19     def test_three_and_its_multiples_are_represented_as_fizz(self):
20         self.__assert_number_is_represented_as(3, 'Fizz')
21         self.__assert_number_is_represented_as(6, 'Fizz')
22 
23     def test_five_and_its_multiples_are_represented_as_buzz(self):
24         self.__assert_number_is_represented_as(5, 'Buzz')
25         self.__assert_number_is_represented_as(10, 'Buzz')
26 
27     def test_fifteen_and_its_multiples_are_represented_as_fizzbuzz(self):
28         self.__assert_number_is_represented_as(15, 'FizzBuzz')
29 
30 
31     def __assert_number_is_represented_as(self, number, representation):
32         fizzbuzz = FizzBuzz()
33         num_list = fizzbuzz.generate()
34         self.assertEqual(representation, num_list[(number - 1)])
35 
36 
37 if __name__ == '__main__':
38     unittest.main()