How to Start TDD?

A short overview on test driven development with practical tips and techniques to get started.
tdd test-driven-development clean code agile

Simply said, TDD is the practice of writing tests first before implementing the code. It starts with writing down the code behaviour we wish to have as tests, followed by the implementation. This is done one step at a time, switching between tests and implementation. In TDD, we let the tests guide the implementation, which means that code is written according to the requirement - not more not less.

What are the benefits of TDD?

  1. Boost confidence in code that works
  2. No fear in making changes to the code. Tests will tell if behaviour changes.
  3. Code becomes more flexible, maintainable and reusable.

There are multiple ways to describe a TDD approach, here are 2 famous ones:

The three laws of TDD by Uncle Bob:

  1. You may not write production code until you have written a failing unit test.
  2. You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
  3. You may not write more production code than is sufficient to pass the currently failing test.

Rhythm of TDD by Kent Beck:

  1. Quickly add a test
  2. Run all tests and see the new one fail.
  3. Make a little change.
  4. Run all tests and see them all succeed.
  5. Refactor to remove duplication.

Following these guidelines, coding becomes a series of short bursts of writing tests followed by writing code that pass the tests, also known as the Red Green Refactor cycle.

Red Green Refactor Cycle

Red Green Refactor cycle

  1. Red - write test that fails
  2. Green - write code to pass the test
  3. Refactor - remove duplications

The Red Green Refactor cycle concisely summarizes the previous concepts by Uncle Bob and Kent Beck. We start by writing a failing test which describes the basic behaviour of the code we wish to implement. Then we write just enough code to pass the test. After that, we refactor the code to keep it clean while still passing the tests.

The next cycle begins with adding new tests to describe the desired behaviour in a wider range of scenarios. Next, we write code that will satisfy all test scenarios. After the all the tests are passing, the code may contain duplications and likely to be in need of refactoring. The tests give us confidence that refactoring the code will not change any behaviour, giving us the ability to clean up the mess we made while implementing the solution.

How to get to green?

As more tests are added, constants that passed initial tests fail. Code becomes more generic and abstracted to satisfy wider range of tests. Eventually the implementation evolves towards real implementation.

There are a few practical techniques that can be used to get into the motion of TDD:

  1. Baby steps - start small, take small steps. Start with the smallest and most obvious tests.
  2. Ping pong - pair up and alternate between writing tests and implementation. Person A writes one small test, Person B implements then refactor. Person B writes next small test, Person A implements then refactor. The cycle goes on.
  3. Test for edge cases - null input, empty strings, 0, very large number, very long string, etc.

Things to keep in mind while writing tests:

Things to watch out for:

More advanced testing concepts:

Reading Materials:

  1. Test Driven Development: By Example - Kent Beck
  2. Clean Code. A Handbook of Agile Software Craftsmanship - Robert C. Martin

Stubbing Dependencies in Go

A quick guide to stubbing dependencies in Go
software development go test tdd

Avoiding Test Data Mutation

October 24, 2017
ruby test rspec tdd

An Agile Marathon

People talk about agile sprints, but how about an agile marathon? It takes as much responsiveness to change, if not more, in order to complete a marathon, so why not model a project like one?
agile sprints marathon project