In Test Driven Development (TDD), testing is carried out before any programming. TDD relies on the premise that if testing is good, the test code should be written before a line of code (functionality) is.

Within XP, the writing of automatic unit tests occupies an important place, as writing unit tests is done before an actual program is started. In TDD, the programmer makes one or two tests, writes a piece of the program, makes an additional test case, reworks the program until the new test passes, the designs a new test, and so on.

The advantage of this process is that the programmer is obliged to think about the functionality and the exceptions that their program should take into account; they think about what the program should do first and how the program will work second. In other words, the tests capture the required functionality. It is therefore important that every program only has enough functionality to make the test work. If all tests pass, the program meets the previously-defined requirements, which are defined in the written and successful unit tests.

When refactoring is required, the already-written unit tests are therefore a guarantee that changes will not cause undesirable side effects in the operation of a program.

Should it be necessary to expand a program with new functionality, the first thing to do is to start writing new unit tests that will define the new functionality to be written. This new functionality is only realized when both the new and the old unit tests all succeed.

If a bug is found at a later stage during a functional test, writing a unit test that brings this bug to light is the first port of call. A bug is therefore not a fault in the program, but rather the result of an insufficient test.

To summarize, a software development project that is carried out using TDD does the following:

• Starts with one unit test that describes one feature of the program
• Runs the test, which should ultimately fail because there is no code
• Utilizes the minimum amount of code needed to make a test pass
• Rewrites code to make it simpler
• Repeats the process with more tests

Using this approach, the defect rate should go down after time, despite more time being needed to get things started. Most teams report that once they have reached the end stages of a project, the upfront testing cost is paid back and they work quicker in a project's final phases. Code that is developed this way tends to be of higher quality than otherwise, because for testing to work, you are forced to create code that is high in cohesion but low in coupling. This keeps code that works on the same behavior and keeps properties in the same class, as well as keeping modules as isolated as possible with clear interfaces to other code.

This approach may sound quite simple, but in practice, it's quite hard, as developers may forget to run tests. However, this problem can be easily fixed by setting up a project template in a CI/CD environment with pre-configured tests, where tests are run at every commit or push. If there are software engineers who are prone to overdo testing, it is a good idea to agree on the number of tests, and how far they will go, beforehand. Don't test constructs that are simple, such as accessors, for instance. On the other hand, be careful not to over-simplify your tests, such as by creating tests but no assertions.

Team culture and agreements are very important for testing. If some team members aren't on board, you will have conflicts. Also ensure that any test-templating, automation, or suites are well supported, or your tests will break. (This also means that several people should have knowledge of these products.)

In essence, TDD can really improve the quality of your software. This is especially true if all tests are automated via a continuous process, which we will discuss in the following section.