If you’re not new to software development, you’re probably already familiar with test-driven development (TDD). As a quick refresher, TDD is a development process where the software requirements are made into test cases before the implementation code itself is written. In TDD, there’s a cycle called Red - Green - Refactor. First, write tests and see that they fail. Then do the bare minimum to make the tests pass. After making sure that they pass, refactor the code to make it better (e.g. implementing clean code).
This whole thing might sound a bit counterintuitive. Why would I test something that hasn’t been built yet? Isn’t it more logical to code first, then test the software?
It turns out there are some reasons why TDD is a thing (duh). Let’s see what benefits TDD can provide us with.
Benefits of TDD
Simpler Code
Sometimes people write complex code that can be overkill for the actual requirements. With TDD, you start implementing a feature only with the purpose of ensuring that the test passes. This way, you don’t end up writing unnecessary lines of code.
You Don’t Miss the Requirements
Since you have transformed all the requirements into test cases, you can be sure that they’re all satisfied when all the tests pass.
When Something Fails, You Know What Went Wrong
Imagine you’re developing a software without writing any test. The software works fine at first, and you start implementing new features on it. When you try to run the software to see your new features, it crashes. You can’t find what went wrong, and you wish you had used TDD.
TDD ensures that when the code is modified, the functionality doesn’t change. This is especially beneficial when working in a team, since the code that we’re modifying might be written by another person.
Shorter Delivery Time
As mentioned above, the focus in TDD is making sure that the tests pass, so the developers don’t waste time doing unimportant tasks.
How I Implement TDD in My PPL Project
In developing IGRI for the PPL course, the team and I strictly implement TDD. Failing tests commits are marked with [RED] flag, implementation commits with [GREEN] flag, and code refactoring commits with [REFACTOR] flag.
Another important aspect of TDD is code coverage. We use SonarQube to measure the code coverage. It’s not yet perfect, but we keep trying to increase the coverage to reach 100%.
The Code
Let’s take a look at how I write the code. For one of IGRI’s features, I needed to create two objects in the database: Topik and Artikel. Before doing that, I wrote the following test cases first.
When I tried running the tests, they failed, as expected. Now that I had the test cases, I could confidently implement the code to create the models.
After writing the above code, the tests passed. Nice!
Is TDD For Everyone?
As promising as it sounds, TDD may or may not be right for your project. Projects that focus on functionality, require a short implementation time, require modulation and continuous development are great candidates for TDD. However, if you’re working with existing projects that don’t have unit tests, it might be cumbersome to start implementing TDD. Also, remember that more complex projects mean much more code and tests. If you’re developing a complex app, consider the time it would take to run all the tests and how it might increase the costs.
Conclusion
TDD is a great tool to maximise the efficiency of software development. However, in the end, it’s just a tool. Like other tools, it’s up to us to make the most out of it.
Reference
This post is written as an assignment for the PPL course at the Faculty of Computer Science, UI.
