TDD: Test Before Implement
Have you ever experienced many bugs in your project even though you are very confident with your tests and implementations? Are you sure you have followed the Test Driven Development (TDD) principles?
In 1999, Kent Beck, an American Software Engineer, invented TDD. Test Driven Development is related to the Test-First Programming concepts of Kent Beck’s Extreme Programming. This is opposed to software being developed first and test cases created later.
Test Driven Development starts with designing tests and make them fails. After that, we implement the codes to pass the tests. With this principle, we only need to code if the test is red or fail.
In this post, we will see how important is TDD to improve code quality.
Test Driven Development (TDD)
The simple concept of TDD is write tests to validate codes. This helps to avoid duplication of code as we write a small amount of code at a time in order to pass tests.
There are three general steps in TDD:
- [RED], this means we implement the unit tests first. It’s called [RED] because we haven’t had the code implementations yet. So, the unit tests will fail at first. We need to note that we must find various conditions in creating the unit tests to have better code quality. Think and create the unit tests just like you are a naughty user trying to find bugs in your system for your own sake, with all possibilities.
- [GREEN], implement the minimum code to pass the tests. If the code is still failing to pass the tests, write more code (but still the minimum code) to pass the tests. By following this, we can make sure our implementation doesn’t have duplicate codes.
- [REFACTOR], do this if there are still possibilities to enhance and improve your code without failing the tests. Make sure our new, enhanced, and improved implementation doesn’t change the original behavior of our old implementation.
Implementation in Software Engineering Project Course 2021 Fasilkom UI
I used TDD approach to implement features in my Product Backlog Items (PBIs), in Software Engineering Project Course. For example, this is my TDD approach on my PBI about Authorization.
[RED] — I created unit tests to authorize if the current distributor user is eligible to access distributor resources and forbidden to access admin resources, and vice versa for the admin.
[GREEN] — After that, the authorization and its corresponding permission is implemented to pass the test.
[REFACTOR] — We can refactor the codes to suits our needs without changing the original behavior of the code.
- Write minimum codes. We only implement the codes based on tests. If our project needs another feature, we can write the tests first to drive our implementation. The written code is the simplest code possible.
- Easier to maintain. Because we have the minimum codes, we have modular and clean codes. Thus, we have maintainable codes. If there are enhancements and improvements, we can also refactor our codes easily because of the modularity. As a result, we also have less-debugging codes. When we write tests, we also document the codes.
- Not 100% guaranteed. Write tests help us to seek out bugs, but they can’t find bugs that we introduced. Hence, we need to be careful when writing tests.
- Slow process. Majority of us consider TDD as a slow process, because we need to think and create the tests first before we’ll finally start to write the codes.
I think that TDD gives more benefits, we can see that the advantages outweigh the disadvantages. If we create the tests with earnest, TDD won’t disappoint us. Despite of getting much cleaner code, your production code is also bug-free.
Trust me, even though this process is slower, but you won’t be invaded by accumulated future bugs!
I myself choose to not fight with future bugs, so I will do TDD, how about you?
Thank you for reading, and happy testing!