Photo by Scott Graham on Unsplash
I still remember when the first time I searched at Google "is unit test worth" and luckily it's a common questions, so to find out the answer is easy. Reviewing from the experienced developer around the world, concluded that unit test is worth, from there I started to learn unit test. And guess what, when the learning journey start, I found myself that unintentionally, I learn about new bunch of stuff such as Clean Architecture, SOLID principle and Clean Code, it's like hitting 4 birds with a stone. Awesome!
Fun fact that, I was also found that some people believe that unit test is not worth.
Well, let me share my experience why unit test is worth
Makes your code better
Writing Unit Test make sure you write the code in smallest piece as possible, when you do, normally the code is loosely coupled. Simply loosely coupled is a code that has single-responsibility, not dependent to other component and separation of concerns.
Increase the bug-less confidence
If you don't write unite test, do you ever feel like when you push your code to the repo, senior checks, merge to the master, deployed to production, you feel paranoid like "will my code run ? is my test coverage good ? what if there's a bug ?"
You know what ? I ever feel that. But since I write the unit test, I can say that I have confidence that my code will not buggy, maybe slightly paranoid, because there are no perfect software, there will be a bug. Ok enough for that, let's discuss another case from my experience.
We are living in agile world, which means everything will be changed, the software will grow bigger, the code will be updated. Let's say you develop a feature that written in FeatureA() function. The feature works expectedly, no bug or such thing, everything is perfect as expected.
And one day... your manager requests a new feature and a requirement change, that makes you create a new FeatureB() function and change that FeatureA() function. You push your code, deployed to production, the customer uses the feature you developed, no bug, everything is work perfectly...
And one day... your manager requests another new feature and requirement change, he requested new 5 features that makes you create new 5 functions, FeatureC() - FeatureG() and let's say the function depends on FeatureA(), and manager requests to change the FeatureA(). You add the features, update the code, you test it manually, you found bug, you fixed it, you push the code to the repo, it's deployed, the customer uses your feature, and.....they found a bug in your app
So simply recap from that story/my experience, that in this era of agile, when the requirement change so fast, you can't be confident by your manual end to end test by yourself, you need to do it automatically, recheck all the feature, especially the dependent one, before you push to the repo, and deployed to production, make sure your code is bug-less with the help of unit test, checks all the feature, and be the most confident person in the earth with your code.
It help to document the code
When I review the code, rather than reading the code implementation, I will start from the test package/folder. Because it is fast, comprehensive, save my time.
The developer will write the test in function like SaveUserTest() it is more respected if the test follows the BDD (Behaviour-Driven) which you specify the Given When and Then (I think will make a post about this soon)
Takeaway
Shortly, stated from above I suggest that you learn the unit test, and implement it to your code. If your company's culture is yet implemented unit test, I think this is the time, ASAP. Simply because it's worth it
Top comments (0)