Understanding Test-Driven Development (TDD)
Is it worth your time?
I’m sure as a developer, you were at least once in that phase of denial when a project even mentioned the phrase ‘Test-Driven Development’. Or maybe you’re still not over it yet, and you’re here to remind yourself why you should do it all backward — test first and then write.
So, is Test-Driven Development (TDD) worth your effort? The short answer is yes, though how it came to that conclusion is not as simple. According to Agilealliance.org, although the effort in initial development is increased, many teams reported fewer defects and a reduction of effort in the projects’ final phases.
The question now is, how do you go about it?
How to TDD
Kent Beck, the one who popularized the development process, started it all with his book “Test Driven Development: By Example” on which I will base the sum of this article. TDD is basically a process that could be succinctly described in the following order:
🔴 RED — Write a simple test that doesn’t work. The test should be short and have just one responsibility. This failing test is intended to make sure that your code is not working accidentally.
🟢 GREEN — Make the test work quickly; write just the minimum amount of code.
⚪️ REFACTOR — Eliminating the duplication both in the test and code. Better yet, clean code it!
Clean Code
In accordance with Robert C Martin in his book “Clean Code”, tests should follow the F.I.R.S.T principles:
- Fast: Tests should run quickly. When tests run slowly, they probably wouldn’t run as frequently. This means you wouldn't detect the bugs (if there are any) as early.
- Independent: You should be able to run tests independently and in any order you like. When tests depend on each other, it made diagnosis much more complicated.
- Repeatable: You should be able to run the tests in any environment.
- Self-Validating: Tests should have a boolean output. In that case, it is self-validating. Imagine if a test returns a log file, then the diagnosis will be subjective to the one currently in charge.
- Timely: Tests should be written just before the production code in order to consistently write testable production codes.
Code Coverage
Code coverage is a metric that helps you detect how much of your code has been covered when you run your tests. With a coverage report, we will know what percentage of our production code has been executed to measure the effectiveness of our test code. Although the use of code coverage doesn’t guarantee proper utilization of TDD, agilealliance.org states that coverage below 80% is likely to indicate deficiencies in a team’s mastery of TDD.
An Example
Here, I will give an example of how I implement TDD on my software development group project whilst using git for version control.
What I attempted to do here is write a failing unit test that has a single responsibility.
After, I wrote a simple production code that passes the test I made before. As it were, I didn’t carry out a REFACTOR because both my production and test code don’t have any duplication. If they do need it, then my commit would look similar to the couple above with a [REFACTOR] prefix.
Now, TDD is just one of many tools you can use to make quality code. At the end of the day, you’re the one that gets to decide which works best for you and your team.
As stated by hackernoon.com, the TDD book by Kent Beck is a reference for all agile enthusiasts. Check out my previous article if you want to learn more about agile SD and how to maximize it for your team!
