Test-Driven Development (TDD)

TDD is a method of development largely popularized by Kent Beck in the early 2000s. The goal is to create a software step by step, by writing tests before writing code while continuously refactoring.

The Three Laws of TDD

TDD has three very important laws :

• You must write a failing test before writing code for production.
• Only write the minimum amount of a test, no more than its need to fail.
• Only write the minimum amount of production code for the test to pass.

The Red-Green-Refactor phases

These laws are applied in the 5 following steps, also called "Red-Green-Refactor" phases :

• Red: Write one unique test which describes a part of the problem to solve.
• Red: Check if the test fails, this means the test is valid, because the corresponding code doesn't exist.
• Green: Write just enough code for the test to succeed.
• Green: Check if the tests pass
• Finally, Refactor the code.

And repeat until you find yourself struggling to refactor anything.

The idea is that you can't make clean and functional code in one go. Kent Beck explained it as :

Make it work. Make it right. Make it fast.

Acceptance test–driven development (ATDD)

The principle is to promote collaboration between the client, testers and developers by writing acceptance tests before writing the actual code. These tests describe how the app will function and help understanding the actual needs of the client. It is also a way of checking if the software works as planned.

These acceptance tests represent the user’s point of view (User stories) and act as a form of requirements to describe how the system will function, as well as serve as a way of verifying that the system functions as intended. In some cases the team automates the acceptance tests.

The steps of ATDD are very similar to the ones in TDD, but here the client is present :

• Define the needs of the test with the client
• Write the functional test
• Check if the test fails (because no code is written yet)
• Write the minimum amount of code for the test to pass
• Check if the test passes
• Write the entirety of the code

• Run the test to check if there is any sort of regression

  
  

The User stories are represented as charts. A very simplistic example would be this one :

Behaviour-Driven Development (BDD)

BDD is a mix of TDD and ATDD. It uses the 5 steps of TDD, and the collaboration of ATDD. In addition to that, a new language is created. This language is in very simple, plain English, and helps facilitate communication between teams.

BDD was created, because its creator (Dan North) thought TDD could not give an optimum quality, and prevent 100% non regression.

These tests are like scenarios, where you write each steps required to complete the test, like logging in a website. These tests are written before any code (just like TDD), using the new language called Gherkin.

Feature: Title of the scenario
Given [Preconditions or Initial Context]
When [Event or Trigger]
And [Additional element]
Then [Expected output]

Example of use :

Feature : The user logs in the website.
Given the user is on the logging page.
When the user inputs his credentials.
And their credentials are valid.
Then the user is logged in.

I hope my article helped you understand a little bit more what all these acronyms really meant.

Many other exist, such as Event-driven development (EDD) and Story driven development (SDD), Feature-driven development (FDD), Example Driven Development (EDD again)... feel free to do your own research to know more about these ones, or the one I already talked about, there is much more to learn on the matter !