One of the principles from 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 –
- A failing test case is written
- Enough business code is created which makes the failing test case pass
- Then, if needed, the entire code is refactored.
- Finally, the entire process is repeated, creating more tests over a period of time.
Things to consider when creating tests:
- Only one assert per test.
- The test should be fast.
- It can be run independently.
- It can be repeated.
- It should be self-validating.
What are the Advantages of TDD
1. Faster feedback on the quality of the code.
2. Faster detection of defects.
3. Improved quality of code.
4. Code addition is incremental, thus supports emergent design and architecture.
5. Supports smaller and iterative changes to code, thus making it less error-prone.
6. Makes the implementation of new code easier.
7. Helps to ensure that previous code is not broken due to new changes.
8. Creates a habit of refactoring.
9. Support clean and maintainable code.
10. Lays the foundation for automation.
What are the Common Pitfalls While Doing TDD
1. Writing too many test cases at once.
2. Focus only on a happy path and code coverage.
3. Not thinking about different possible scenarios.
4. Too many assertions in one test case.
5. Testing too many things in a single test case.
6. Writing trivial test cases to improve code coverage.
7. Not executing the test suite often.
8. Not following the steps regularly. Sometimes, just implementing the code without writing the tests first.
9. Using asserts without actually testing anything.
10. Creating 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.
Although it looks like too much code, it is just one failing test case and some initiation code. Here, we have created a test case which is asserting that if the length of the username is 5, then it should receive an error message – ‘Length of Username should be at least eight characters’.
To do that we are calling a function “validateUserName” which takes a string argument. And this function is part of the “ValidatorService” class which is being initiated in the setUp function of our test class.
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 “dataprovider” 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.
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.
An enabler; helping teams in their journey to pursue agility. I believe that happy teams build happy products. Build teams around motivated individuals is my daily mantra. He is having having fifteen years of experience in the industry and have donned various roles earlier.