Test-Driven Development is a software development methodology/technique that involves the creation of tests first, even before the application code exists.

But… how does it even work?

Don’t worry, keep reading. Hopefully afterwards you will be tempted to try it yourself (spoiler alert: it will reduce the number of failures).

What Is TDD?

The definition of Test-Driven Development (TDD) is as simple as that: software development that will depend on tests made for the planned features.

The goal of of TDD is to convert requirements to specific test cases without waiting for the actual code. It greatly improves the development cycle and product quality, as it makes sure that a new feature is not failing and that it meets the requirements proposed by the client.

In 2003, Kent Beck, who popularized the technique, said that Test-Driven Development encourages simple design and inspires confidence.

How Do You Apply It?

The general (and iterative) approach is: red, green, refactor. Let me explain it,

Create the test. It will fail because there is no feature code associated with the test, yet.
Test passes. The minimum amount of feature code is added to the build to make the test pass. The code is not complete, but now the test is not failing.
Go through it and refactor every line that needs it. No worries, now you have a test that will let you know right away if you break something.

TDD is also based on non-operational objects. These objects are is basically a way of adding these fake behaviors, states, and data to make the testing flow simpler. The focus is on what is needed for the test, not the whole system.
You can learn more about dummy, fake, mocks and stubs objects online.


  • Traditional development may start “later” due to test writing.
  • Tests themselves have to be maintained.
  • If you come from traditional development, it will take getting used to it.
  • The whole test suite needs to be in sync with feature additions.
  • Harder to adopt in ongoing projects or legacy code.


  • Once started, development goes faster.
  • Only new features have to be tested and debugged. Older features are already covered by existing tests.
  • Test coverage aggregates and grows wider.
  • Quality is improved throughout the project.
  • Developers get constant feedback and don’t have to wait until the build fails.
  • Maintainability is easier.
  • Improves collaboration between developer and testers, and even product managers.


This approach on software development may be new to some teams, but it actually has been around for more than 20 years. Following it will lead towards better quality product. It may feel like it does more slowly at the beginning, but it will go faster overall.

Now, this may sound like a lot more of work for you and your team, but in the long term are it has more PROs than CONs.