Test-Driven Development




Test-driven Development is a programming practice that instructs developers to write new code only if an automated test has failed, and to eliminate duplication. The goal of TDD is clean code that works.

__Massol & Husted: JUnit in Action

Test Driven Development is the craft of producing automated tests for production code, and using that process to drive design and programming

For every bit of functionality, you first develop a test that specifies and validates what the code will do.

You then produce exactly as much code as necessary to pass the test. Then you refactor (simplify and clarify) both production code and test code

__Agile Aliance

Source: Brian Nielsen, Arne Skou. Test Driven Development. Retrieved May 30, 2017 from https://goo.gl/lfyX48

The Steps of TDD

Three Step Of Tdd Source: Matt Chernosky. (2016, March 14). How to Write Better Unit Tests For Embedded Software With TDD. Retrieved from https://goo.gl/4Y6OtZ

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle. It can be succinctly described by the following set of rules:

  1. write a “single” unit test describing an aspect of the program
  2. run the test, which should fail because the program lacks that feature
  3. write “just enough” code, the simplest possible, to make the test pass
  4. run the test again to ensure all the tests pass
  5. “refactor” the code until it conforms to the simplicity criteria
  6. repeat, “accumulating” unit tests over time

Adapted from Agile Alliance. TDD Glossary. Retreived May 30, 2017 from https://goo.gl/2EcEZz

The Three Rules Of TDD

  1. You are not allowed to write any production code unless it is to make a failing unit test pass.
  2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
  3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

You must begin by writing a unit test for the functionality that you intend to write.

But by rule 2, you can’t write very much of that unit test. As soon as the unit test code fails to compile, or fails an assertion, you must stop and write production code.

But by rule 3 you can only write the production code that makes the test compile or pass, and no more.

Source: Robert C. Martin (Uncle Bob). The Three Rules of TDD. Retrived May 30, 2017 from https://goo.gl/6Y2ir5


Atdd And Tdd

Test-driven development is related to, but different from acceptance test–driven development(ATDD).

TDD is primarily a developer’s tool to help create well-written unit of code (function, class, or module) that correctly performs a set of operations. ATDD is a communication tool between the customer, developer, and tester to ensure that the requirements are well-defined.

TDD requires test automation. ATDD does not, although automation helps with regression testing. Tests used in TDD can often be derived from ATDD tests, since the code units implement some portion of a requirement. ATDD tests should be readable by the customer. TDD tests do not need to be.

Source: Wikipedia


Given When Then Source: Abhay Kumar - LinkedIn

BDD (behavior-driven developmentcombines practices from TDD and from ATDD. It includes the practice of writing tests first, but focuses on tests which describe behavior, rather than tests which test a unit of implementation. Tools such as Mspec and Specflow provide a syntax which allow non-programmers to define the behaviors which developers can then translate into automated tests.

Source: Wikipedia



See more books at Suggested Reading for Professional Scrum Developer





Exercise 1 - FizzBuzz

This can be your first exercise to practice TDD. It is a good exercise for you to start and give you the real feeling of TDD. Don’t feel bad if you couldn’t do it well as this happens to everyone who start practicing TDD for the 1st time including myself :)

Click here to start

Exercise 2 - Roman Numbers

In this exercise, the implementation of the logic is not so obvious like in the exercise 1. Please use TDD approach to write your code and tests that are easy to understand, change, and maintain. You will also apply data-driven testing technique in this exercise.

Click here to start

Exercise 3 - Circular Buffer

In previous exercise 1 and 2, you write only 1 method to solve one single problem with obvious acceptance test cases. In this exercise, you will practice gathering requirements, writing acceptance test cases, and do a bit upfront design. You will also need to write several methods to make all the functionality work.

Click here to start

More Exercises

Please visit these websites for more exercises (Code Kata):


Exercise 1 - FizzBuzz

Exercise 1.1

You are going to write a function “Say” with input of integer and output of string. The function return the integer itself except these numbers:

Here are sample outputs from the input 1 to 15:


Please try implement this function in TDD way. Do not look for the solution on the internet before you try on your own. Different developers might come up with different codes.

Once done, check: Does your test code has good readability? Do you need to move around your code or your mouse in order to read your code?

Exercise 1.2

What if we want to add more logics:

Here are some sample inputs/outputs:
7 = Wow
14 = Wow
21 = FizzWow
35 = BuzzWow
105 = FizzBuzzWow

Does your code has good maintainability? Can you add these logics without touching existing codes?

Exercise 1.3

What if we want to change some wordings:

Does your code has good maintainability? Can you change these words without touching existing codes?


Please check out a solution on GitHub repository per below links. See how to trace code changes step-by-step from this blog.


Exercise 2 - Roman Numbers

Exercise 2.1

Do you know how to write Roman numbers? If you do, please write a method to convert an Arabic number (integer) in to Roman number (string). If you are not sure how to write Roman numbers, you may check Wikipedia or see this chart. Below table represents Roman symbols for numbers for your reference.

Please implement this method using TDD approach.

Exercise 2.2

You may notice that you have a lot of test scenarios and test cases. Try to implement your tests using data-driven testing technique (i.e. Parameterized in Java or eCATT in ABAP).


Please check out a solution on GitHub repository per below links. See how to trace code changes step-by-step from this blog.


Exercise 3 - Circular Buffer

Exercise 3.1

You are developing a class with several methods to handle data structure called Circular Buffer. First, try to understand how circular buffer works from Wikipedia. List out attributes and methods that your class should have. Give them proper names and define the input parameters and output parameters for your methods.

Circular Buffer Animation A 24-byte keyboard circular buffer.

Exercise 3.2

Implement your class. Pick a method to start. Remember that you are doing TDD so you should begin by writing a test first. Complete each method one by one. Add attribute only when you need.

Observe which method did you pick first and how do you pick the next one. Find out what is the best way to do.

If possible, try to do this exercise with your friend(s). Every five minutes, change to another machine and continue coding from your friend(s). This is the best way to determine how good readability your code is :)