What is Test Driven Development (TDD)? Tutorial with Example

One of the principles of a manifesto for agile software development states that - Continuous attention to technical excellence and good design enhances agility.

But how do we focus on technical excellence? Well, for that we need to explore a bunch of good and useful technical practices. One such practice is Test Driven Development or TDD.

In this article, I would walk you through a simple example of creating a Test-Driven code and elaborate a bit about the practice and associated advantages.

What is TDD?

TDD or Test-Driven Development is a common practice for developing code that is simple, maintainable, and well-tested. The approach states that one should write “implementation code” only if there is a “failing test case”.

It is an iterative approach for developing software products where -

1. A failing test case is written
2. Enough business code is created which makes the failing test case pass
3. Then, if needed, the entire code is refactored.
4. Finally, the entire process is repeated, creating more tests over a period of time.

Things to consider when creating tests:

1. Only one assert per test.
2. The test should be fast.
3. It can be run independently.
4. It can be repeated.
5. It should be self-validating.

What are the Advantages of TDD

• 1Faster feedback on the quality of the code.
• 2Faster detection of defects.
• 3Improved quality of code.
• 4Code addition is incremental, and thus supports emergent design and architecture.
• 5Supports smaller and iterative changes to code, thus making it less error-prone.
• 6Makes the implementation of new code easier.
• 7Helps to ensure that previous code is not broken due to new changes.
• 8Creates a habit of refactoring.
• 9Support clean and maintainable code.
• 10Lays the foundation for automation.

What are the Common Pitfalls While Doing TDD

• 1Writing too many test cases at once.
• 2Focus only on a happy path and code coverage.
• 3Not thinking about different possible scenarios.
• 4Too many assertions in one test case.
• 5Testing too many things in a single test case.
• 6Writing trivial test cases to improve code coverage.
• 7Not executing the test suite often.
• 8Not following the steps regularly. Sometimes, just implement the code without writing the tests first.
• 9Using asserts without actually testing anything.
• 10Creating test cases that aren’t maintainable.

A TDD Example

Let us consider a user profile management system that allows users to create a username and password for future authentication. There are certain business rules which the username and password should follow to be valid.

For the sake of simplicity and brevity of the article, I will work with only one rule for the username and that would be to validate the minimum length of the username. Let us say that the minimum length for a username is 8 characters. Now we will start developing our tests and code accordingly. I will be using Laravel and PHPUnit for the code examples.

Step 1: Write a failing test case.

Now let’s go and run the unit test.

And we get an error which is quite expected since till now we have not yet created the “ValidatorService” class.

Let us create the class and run the test again. Remember, we are writing just enough code to ensure the failing test case passes. An error is also a failure, so we will write just enough code to make the error go away.

Oh, an error still exists. But now it is different. As expected, now it is looking for the function, which is still not there. Let’s create a placeholder function and execute the test.

And, now we have a failing test case. We will now create the actual code for the functionality to validate the length of the username and execute the test case. The failing test case should now pass.

And it does. Let’s add one more similar test and see if that also passes. It should.

And, yes we have two passing test cases. Let’s add a more generic test case now and execute it.

And all three test cases have now passed. But look at the code it looks like a lot of repetition. Seems like it is now time to “Refactor” our code. PHPUnit provides a nice feature called “data provider” which makes this pretty simple.

Let’s execute the tests and see if they still pass.

And, yes the test cases are still passing. Let us quickly refactor the implementation code as well.

And, do the test cases still pass? Yes, they do. That means for now our code is in quite good shape.

We can now keep adding more test cases to validate different business rules as needed and keep refactoring the code as and when needed. And the moment we will run our test harness, we will know if something is broken because of the new changes that we add.

Conclusion:

As with any other technical discipline, TDD requires a lot of patience and perseverance to become an expert. Although, once you master it, it becomes a habit that reaps huge benefits.

It helps you to create more maintainable, reliable code and also creates a shorter feedback loop if something goes wrong as you build your product.