TDD (Test-Driven Development)¶

What is TDD?¶

TDD (Test-Driven Development) is a software development technique (not a test writing technique) in which the main idea is to first write tests for non-existent functionality and then write code implementing that functionality. TDD is not the only valid and good software development technique. You can write tests in parallel with writing business logic code, you can write them after implementation, but then it is no longer TDD. In Test-Driven Development, we always write tests before implementation. It was originally part of extreme programming, but is now a standalone technique. The technique was created by Kent Beck (creator of extreme programming and one of the creators of the Agile Software Development Manifesto).

TDD life cycles¶

Writing and running the test (the so-called red phase)¶

The first step is to write a test. This test cannot be successful because the functionality itself is not yet implemented. It is possible that even after writing such a test, the code will not compile. This may be the case if you wrote a test for a method that does not exist yet.

Writing the minimum code to pass the test (so-called green phase)¶

In this phase, we start writing the code responsible for the business logic, we write the minimum amount of code, thanks to which, when the test is run, it goes into the "green" state - that is, into a state that means that the test has been successfully passed. The important thing here is to create a minimum code scope. We are not trying to write the entire module. We are only interested in the code that is under the supervision of our test.

Code refactoring (so-called refactor phase)¶

In this phase, we re-invoice the code so that it complies with all the standards of good programming. Refactor can also apply to tests.

What's next?¶

These three steps close the cycle. We repeat it until we have written all the tests that cover the business logic.

This model can be represented graphically¶

Advantages of TDD¶

For the developer¶

• higher comfort of work - also working with existing code thanks to fewer errors,
• documentation of high-level functionality,
• better business knowledge and thus better product knowledge,
• greater chance of a clean code,
• easier start of work in the project,
• reduction of stress and less pressure at work,

For client¶

• higher level of certainty as to the correct operation of the application and fewer errors,
• the ability to predict the costs of maintaining the application and introducing modifications to existing solutions,
• savings on the implementation of new programmers to work on the project,
• faster locating and fixing any errors,
• a greater chance for interesting suggestions from the developer regarding the implemented solutions, thanks to better knowledge of current functionalities,
• TDD means better code and therefore a better application.

Disadvantages of TDD¶

• time and effort to train and prepare developers,
• the need for personal and team discipline, tests must be managed and improved over time in the same way as all the rest of the code,
• initial perception of longer development time,
• not all managers are convinced by the argument of twice as long development, although the total development time (including bugfinding and fixing, not just code writing) is shorter in TDD than in non-TDD.