How To Write Unit Tests, Elegantly
@rkaavyanKaavyan Software developer at JP Morgan chase “If you don’t like unit testing your product, most likely your customers won’t like to test it either.” — Anonymous Most of us developers have become a bit lethargic when it comes to writing unit test-cases. Why do we get that resistance? I graduated from NIT-TRICHY in 2018. I’ve started my career in JP Morgan by writing Junit test-cases for a legacy application. I can tell you verily, that it’s exhausting to write test-cases for someone else’s developed code. I was frustrated. Like every other aspiring CS graduate, I too had a lot of expectations from my corporate life, like, develop some mind-blowing product, work on the cloud, play around with BigData, and many more. However, corporate life is not always a bed of roses :D. There are two different approaches when writing test-cases is concerned: You follow a Test Driven Development, where you first write the test-cases and then, later on, develop your code from there. You write test-cases when there is a need for regulatory compliance for your legacy product. We all know that the TDD approach originated during the early stage of Agile development, most probably in the early 2000s. Recently, most of the product-based companies adopted Agile standards, and test coverage is one of the crucial attributes of Agile development. So what about the products before Agile? This is where our second point comes into the picture. You write test-cases to make your product mature. What do we gain by writing test-cases? Now we know that writing test-cases is a necessity for your application as it is one of the most important attributes which qualifies your application as mature. On the other hand, you may think, my application is working alright! Why do I need to write test-cases to verify the same? Let me just run you through a few of the problems that you may face if you don’t have proper test-cases in place ☺. Pair programming is a common term in Agile standards where you work with your colleagues in the same code base using agreed web-based version control and collaboration platform, like GITHUB. In this methodology, there is a lot more chance that the feature you were working on was hindered by your partners’ feature changes. These two features may be completely different from one another, but it might cause your feature to fail unreasonably. Later on, to find the bug and fixing it, is such an overhead. If you have proper test-cases in place for your feature, the proximity of finding the bug is easy, reducing your precious time. You might lose control of your application. Day by day, your product will receive a lot of requirements and changes. Your application will grow enormously. Even a single bug in your code can cause multiple failures and a hell lot of confusion. By writing test-cases, you will know every change that is happening in your system. You will be aware of any faulty code that has entered your codebase. In Agile development strategy, these two problems are the most common ones that are faced by any product. How to write elegant test-cases to avoid such detrimental failures? When you start writing your test-cases maybe you could follow a certain methodology which may ease your way of writing test-cases. I’ve encountered a few of those when I started writing test-cases, » Read More
Like to keep reading?
This article first appeared on hackernoon.com. If you'd like to keep reading, follow the white rabbit.