… start using it today!
In this article, you will discover the magic of TDD.
If you are familiar with the typical approach of writing tests, you know that most programmers write the code before they write the tests.
Test-Driven Development describes the opposite logic — first prepare the test and then write the actual implementation code.
I am sure you may ask: “But what’s the purpose of writing a test that will fail in the first instance? Isn’t that a waste of time?”.
- Definitely not.
Starting with the test is a more result-focused approach. You have to think beforehand about what the code should actually be doing before it is written.
“Do one thing at a Time, and while doing it put your whole Soul into it to the exclusion of all else.”
I am quite sure Swami Vivekananda did not think about TDD while saying these words but they describe one of the benefits of this technique — focus on one thing at a time.
TDD procedure
Step 1 — Write the tests and execute all of them.
Yes, that’s true — your code will fail since there is no actual implementation but here is exactly how your second step is defined — you have to make sure your implementation brings you the results that you want.
Step 2 — Write the solution’s implementation
This step should be quick and the code does not have to look perfect yet.
Write just enough code to make all tests green.
Ready? Run the tests.
Step 3 — Run the tests
If your tests are failing, continue working on implementation.
If you see the green light (for all your tests), continue to Step 4.
Step 4 — Refactor
Here’s where your code will look perfect and you can run all the tests again.
If your test is not failing in Step 1 it is most likely the sign of a false positive. Be careful.
What’s the win?
You have just learned about the whole procedure. Now, what’s in for the programmer?
First of all, I would say it’s a future-proof solution. When we start with the tests we are making sure we actually have them in our repository.
In the traditional approach, there is often no time left to prepare for proper tests. What I often observe, especially in the Agile approach is that there are no more estimated points left to take care of tests and people do not dare to ask for assigning more time for the given story.
Sometimes the time for tests is not taken fully into account while estimating the work or is being underestimated.
Once we have the tests we are guarded. Any destructive change in our implementation will result in failing tests.
Whenever I am extending complex code not written by me and this process results in failing tests I thank the person in my mind for taking the time for writing the tests and avoiding bigger damage (like buggy software deployed to production).
As you can see TDD has a very positive influence on code quality.
Next, security:
- If your code is guarded with great tests — you can feel like fish in the water while extending guarded implementation. Isn’t that great?
- Stability of your application. If you compare the application with 10% test coverage to one that has half of the code covered: which one do you think is more likely to stop working because of unexpected issues?
Less maintenance time
That argument is of course closely related to the fact of having good code coverage. I could not count how many times I fixed something unexpected because I was writing the test and discovered that.
That means that you will detect bugs more often and quicker. Maybe you will even save a big fire but after a bit of time, you will definitely notice fewer bugs reported and you will feel great knowing that you are building reliable software. Less maintenance means more focus on the actual implementation, extensions, and integrations that customers love.
Summary
Test-Driven Development is a good technique every developer should have in their own toolbox, however, deciding whether this approach should be implemented may be an individual decision.
By applying TDD you will influence the quality of the code and the delivery but it comes with a price of increased time before the delivery.
It’s not “cheap” but it’s cheaper than solving problems you will have when not using it.