Test-Driven Development (TDD) is an approach in software engineering where a programmer creates a series of tests to validate the behavior and components that will be performed by the code they write before implementing the functionality and features of software. Tests for each feature/component are created first and are run after they are built. If the test fails, the developer will start writing the feature code that will make the test pass.

TDD Steps

In the TDD approach, the typical process involves :

1. Write tests (unit/functional)
2. Run all tests and observe the results
3. If tests fail, write code to make the tests pass
4. Rerun the tests
5. Refactor the code
6. Repeat steps 1-5

Issues with Traditional Testing

Traditional testing refers to creating tests (manual/automated) after the features and functionalities are implemented. There is a problem with this approach, which is creating tests at the end that requires testing or covering the entire codebase for the functionalities.

This situation worsens if the code for the feature turns out to be excessive compared to the original intended functionality, a concept known as overengineering. Eventually, the tests that need to be created will be more numerous and more complex.

TDD can prevent the overengineering of code. By implementing TDD, tests are created to match the expected feature requirements. Then, an engineer's task is to write simple and straightforward code to make those tests pass. With this paradigm, the code created is only what is necessary.

Benefits of Applying TDD

1. During the test creation process, our focus is on the desired behavior or function of the code to be written. When transitioning to the coding phase, developers already have detailed program specifications.
2. Time efficiency when modifying code. This is because the detailed expectations of the program are captured in the tests, allowing developers to focus on one thing.
3. Reduced debugging time when making changes or refactoring the code. These tests can be automatically run to identify any behavioral changes that occur during refactoring.
4. More flexible, maintainable, and easily extendable code.

TDD consists of three stages, often referred to as RED, GREEN, REFACTOR. Let's discuss each stage in detail.

RED

When the specifications for a feature are obtained, the first thing to do is to create a unit test representing part of that feature's functionality. For example, if there is a feature to create a navbar, the first test that can be created is to check if the menu items in the navbar are displayed. When this test is run, it is expected to fail.

GREEN

After creating the test mentioned in the RED stage, the next step is to implement the code that makes the test pass. This means the developer needs to create a navbar component containing the menu items in the test. If the test is run again, it should pass.

REFACTOR

In the refactor stage, the code that has been created can be improved without breaking the existing tests. For example, in the case of a navbar, the refactoring process might involve improving the styling of the component. Certainly, changing the text color in the navbar shouldn't affect the status of the existing tests.

TDD in Agile Development

Agile development involves the incremental creation of products, leading to feedback and improvements at each iteration. These improvements can include bug fixes, additional features needed in the next iteration, and ensuring the software meets the requirements. The TDD approach enhances the efficiency of collaboration between the development team and the client during task completion in an iteration. This efficiency is achieved because writing code doesn't consume significantly more time during implementation.

Here is an example of TDD implemented by the Paytungan PPL team:

When the test case is created, it naturally fails initially because the login page has not been implemented yet. This page aligns with the backlog requirements. Since the test fails, the commit for creating this test case is labeled as RED.

The next step is to start creating the login component.

Then, adding the code makes the test pass, and it can be committed with the label GREEN.

Once everything is green, the code can be refactored as needed. When the feature is complete, tests can be run to check code coverage and the success status of the tests. An example from Paytungan: