Sharing is caring!

Overview

Agile methodology really gains its momentum as per now. Many organization choose Scrum in a way to develop a software. Their decision to pick Scrum literally because they want to deliver fast to the market. Also, they want to get feedback faster from their customer. Therefore, they can continuously improve the products based on market needs.

If you can spot on why organization choose scrum, the keyword is fast and time to market. Therefore, as a software developer, the scrum implies us to speed up our development time. Oh crap, every methodology impacts developer as a bottom food chain. Well guys, I did not say we have to double our speed by working long hours. Work hard is okay, but work smart is more important. We can double up our speed by automate several development processes. One of the process is the testing process.

Unit Test

Why does it all matter? Why should I write a bunch of unit test instead of just developing? Writing unit test will slow my increment.

I know the feeling when I have to write unit test for the first time. I do understand for all the excuses for not writing it. It was painful and really slowed me down. Just imagine, I wrote a piece of code only 4 hours and I ended up with 2 days by writing unit test. But for everything, the first time is hard and slow. Once you get used to it, everything is quite easy and faster. Relatively.

Back to the correlation between Scrum and unit testing. In every sprint our focus is only its sprint goals. Scrum does not recognize code hardening event. Whether we break the existing logic or not. All those things will slow down our sprint. For this reason, I really gain the benefit by having unit test at the first place. Because it leaves me little to no worry about breaking existing code. I will know once I break the existing logic just by running all the tests.

Unit Test Coverage

Once you unit test your code, the next step is to measure your coverage. Sometimes we call it code coverage.

Code coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs. Wikipedia.

Many people ask how much is the minimum code coverage. I will say it depends. If you are new to unit testing, my best advice is just write it first without thinking a minimum coverage. In contrast, if you have experience in unit testing, try to reach minimum 80% coverage. However, in the end it depends on your organization to set the minimum standard.

My best coverage so far? 100%. I know many people will argue this can lead to wrong purpose if you aim for 100%. But for once in a lifetime, why shouldn’t I try to hit the perfect number :).

Continuous Deployment

One of the important software delivery process is continuous deployment. Basically, this is the process of build, test, deploy and release the software. With this approach, you can produce software in short cycles, and ensure reliably released at any time.

The important words for this process is short cycles (aka fast) and reliable. How can we achieve it? I guess you already know the answer. Of course, by having a good quality of your deliverables. Good quality means good testing. And your testing should be fast. Therefore, your testing should be automated. The good news is: unit testing is fast, automatic and relatively can cover almost every logic inside your code.

Conclusion

In general, whenever you code, you have another obligation to test your code. And you can test your code automatically by writing unit test. Because unit test is a foundation for delivery process, if you have those habits, your organization will easily move into the next level for delivering the software.

Remember, if you want to deliver faster, you have to write unit test.