TDD .misperception .misconception
What went wrong?
Most of you already know how TDD works, “Test First, Code Later” or following the cycle below.
TDD based on the idea that if developers write test first, they can write better code and possibly easier refactoring process. In TDD, Developers encouraged to consider how the software works and how it will be used before writing the actual code. After Developers write the tests, then the implementation process will be easier, cause they just need to write the necessary code to pass the test.
We need to dig deeper on why TDD, and how our team implement it in our PPL Project
TDD makes…
You focus on the acceptance criteria
When writing code, you usually have a list of acceptance criteria that needs to be met. You can use these to know what you need to test and focus on one criteria, then once you done writing your test code, you can rest assured that you have done with the criteria and can work on the next one.
Your code more modular
As you write test, you also think how to write a function that can pass the test on itself. This way, your code can be reuse and cleaner.
Up-to-date documentation
Test can also be a live documentation on how the code works and what to expect .
Confidence in Deployment
Knowing that your code already tested in local and CI, we will be assured that the code works and we can continue to do the next assignments.
Safer Refactoring
When you refactor your code then the test fails, you know you broke something with your code before deployment.
Misconceptions of TDD
Most Developers does not know well what is TDD and why we need to implement it, here we gonna debunk some misconceptions:
TDD makes us slower
Probably the most common excuses for not testing. In fact, it can reduce development time for reducing bugs. Developers can be more productive on making new features rather than trying to figure out what went wrong before.
You need to write all test before write code
TDD is an iterative process, means that you do not need to write many test before implementing. Also writing test is exploratory, if you do not like it and it does not have any relation with any acceptance criteria's, you can throw it. So, you can just:
- Write one test
- Make it fail
- Write code to make it pass
- Repeat
100% Code Coverage Dream
Most Developers got this wrong. 100% code coverage does not mean your code is bug free, bad test can pass false positive. Instead, you should focus on getting 100% feature coverage, not line coverage. Also, what you need is to write good test that does not return a false positive and reflects on the user scenarios.
TL;DR
TDD is a software methodology that encouraged developers to write test before writing code, so developers can consider how the software works and how it will be used.
TIPS : Our PPL team use tags on commit message to make communication easier between members.
That is all for know, see you on the next article!
Reference: