PPL 2020 — Document Builder: TDD, Is It a Religion?
This post is written as a part of individual review criteria of Fasilkom UI’s software engineering project course: PPL 2020
Test-Driven Development. If you’re a software developer, chances are you’ve heard this before. For some people, TDD is god’s word. They practice TDD as if their after-life depends on it.
For some people, like me for example, I see TDD merely as a convention, far from god’s word. I personally don’t think that not practicing it is a pathway to the hell of software development.
Convention in software development is for me like any convention in the world. It’s an agreement. You agree to do something, you do it.
In our software engineering project course: PPL 2020, we have this TDD convention. The difference is the course participants don’t really participate in giving consent or having any say in the convention. It is a requirement. We have to do it, like it or not.
If you’re faced with the same kind of situation as the rest of us, having to develop software with TDD without any choice of bailing out, I intend this post as an exploration and reflection of what TDD really is, why do we need it, and how to make ourselves comply with the TDD god and her worshippers.
What is TDD?
Test-Driven Development or TDD is a software engineering discipline. It revolves around the idea of “test first, implement later”. In TDD, we practice the 3 holy steps:
- Test fails, or what we like to call RED
- Test passes, or what we like to call GREEN
- Refactor code, or what we like to call REFACTOR (sorry to disappoint but it’s not BLUE)
In agile software development, TDD supports the trends of continuous delivery. It is said to be able to help developers focus on reaching goals by only building minimum functionality to pass the tests.
This promise of supporting continuous delivery and agile software development comes with its pros and cons. I personally think that knowing what’s good and bad about something is important regardless of whether you’ll be supportive of it or not. So before praying to TDD like it’s a god or directly step on it and discard it, I encourage you to look at this list of the pros and cons below.
The pros
It helps developers identify bugs and edge cases early
By focusing on writing tests, you will identify things that could happen to your functions or your applications as a whole early in the development cycle. When we write tests after we write our implementation, during the implementation, we often forget about edge cases and focus on making it work. This is the aspect when TDD can help discipline developers in identifying bugs and edge cases.
It definitely helps in making code more modular
We need to write code that is easy to test, and hundreds-line-function wouldn’t be easy to test. When we write the tests first, we want the tests to be easy to write. For the tests to be easy to write, we need to have modular functions to test. This is a kind of force to do the right thing that we create ourselves as we implement TDD.
It can speed up development in the long term
Writing tests could be a hassle and feels like a waste of time in the beginning, but as we have more tests and as we are feeling more confident in the code coverage, the time that could be saved can grow exponentially as more code grows and tests are already available to cover them.
It can make developers more confident and feel at ease when shipping out code
When we implement TDD, we prioritize on writing tests. This could produce a sufficient number of tests and we can feel more confident when we push features through continuous delivery. This is highly correlated with the speed of development and productivity of developers.
The cons
When product requirement changes, the tests also change. A lot of time can be wasted writing tests that will be discarded.
TDD supports the agile method of software development, but in some way, it can backfire. When requirement rapidly changes, the tests written also prone to changes. When a feature is dropped, the tests will be dropped as well. This exposes the project to risks of wasting time on writing tests that will be discarded.
Focusing more on passing the test than the implementation can lead to the need for a major code refactoring later.
When we implement TDD, we focus on making as small implementation as possible in the code to pass the tests, this could lead to not paying a lot of attention to code structure and other coding conventions. When faced with tight deadlines, this could lead to a stacking technical debt.
TDD in practice @ Document Builder
In the software that our team develops, Document Builder, we implement the TDD quite casually. We follow the rule of [RED], [GREEN], [REFACTOR] and implement them in our code changes.
My Opinion
The positive impact that I immediately feel when implementing this is a feeling of security. Because I’ve written the tests for any implementation that I made myself, pushing out the code and let the CI/CD works its way through testing and linting the code makes me feel at ease.
In my opinion, TDD is suitable when you’re working on a big project that will be maintained with a team. TDD can help reduce the maintenance effort and the technical debt caused by not anticipating edge cases and code changes.
If you’re working on a one-time project with a very small number of people in your team, I don’t think TDD is something really important that you have to consider. When you don’t need to maintain your project, TDD is just a tedious convention that it will take a lot of your short development time.
While exploring TDD and writing this post, I rediscovered why TDD has some importance in contributing to agile software development. I also discover the mindset of understanding something before we decide to adore it or hate it.
Feel free to use the comment section below to ask any questions or provide any constructive feedback.
Thanks for reading, I hope it was useful :)
