What Is Test-Driven Development and How It Works

Test-Driven Development (TDD) is a process of using tests to design and develop your application.

Why test applications? The goal of the software testing is to make sure that the code you write works as expected and that you don’t break anything when adding new features or refactoring your code. Automation is an essential part of modern software development, so why should you keep doing manual tests over and over again when you have the chance to miss some important test scripts? Instead, let the robots do boring tasks for you.

If you’ve written a set of tests and it works, you can be sure that your entire application performs as expected.

What is Test-Driven Development?

Tests are probably the best way to achieve robustness in a growing codebase. To save time and achieve clean code, we recommend writing code using TDD.

TDD is a process that uses tests to design and develop your application. Its development cycles are typically called Red, Green, and Refactor.

Now let’s delve into details of each cycle.

Let’s assume you want to create a sort_array () function that can sort an array in ascending order.

Red

At this stage, you don’t need to know what your code will look like, you need to know what it will do. Write a test that checks the entire functionality that you want to implement. This will help you see a situation where it doesn’t work.

INPUT: [34, 3, 12, 2]
OUTPUT: [2, 3, 12, 34]

When you run the test, you will see the following error:

Green

Now it’s time to fix the failed test, read the failed test error message, and write code that fixes the current error.

After implementing the sort_array () function, we should see a test passing message that looks like this:

Refactor

At this stage, you need to think about how to improve your current deployment.

If we write another test case to sort the array, we should see another error message that looks like this:

Red…again

The expected result does not match the actual result we get:

WE EXPECT: [3, 8, 21, 99]
WE GET: [2, 3, 12, 34]

This is because we are returning the first sorted array without worrying about other examples (no sorting algorithm is implemented). Take a moment to think about how to go about refactoring the sort_array () function and write the code to sort the array in ascending order.

Now if you run rspec again, you will see that both test cases pass.

As we refactor sort_array (), when we complete the refactoring process and run our test suite again, we should get the following output:

Basically, it’s worth cleaning up your code at this point, reducing any duplication you might have introduced. Make your code modular and efficient. You should feel confident enough in the test you write to make changes without breaking anything.

Three Principles of TDD

Here they are:

• You cannot write code until you first write a failing unit test.
• You cannot write more in a unit test than what’s enough to fail, and failing to compile is an error.
• You cannot write more code than what’s enough to pass a test that is currently not working.

Stay tuned with Software Focus!