The Dark Side Unit Test

"If you don't like unit of measurement testing your production, most likely your customers won't like to examination it either." — Anonymous

Most of us developers have become a scrap lethargic when it comes to writing unit of measurement test-cases. Why practise we go 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 tin can tell you verily, that it's exhausting to write exam-cases for someone else'south developed code. I was frustrated. Like every other aspiring CS graduate, I also had a lot of expectations from my corporate life, like, develop some mind-blowing product, piece of work on the deject, play around with BigData, and many more than. Nevertheless, corporate life is non always a bed of roses :D.

There are two different approaches when writing examination-cases is concerned:

You lot follow a Examination Driven Development, where you commencement write the exam-cases so, afterward on, develop your code from there.

You lot write exam-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 on 2000s. Recently, well-nigh of the product-based companies adopted Agile standards, and test coverage is i of the crucial attributes of Agile development. So what well-nigh the products before Agile? This is where our second point comes into the motion picture. You write test-cases to make your product mature.

What practise we gain by writing test-cases?

Now we know that writing test-cases is a necessity for your application every bit it is 1 of the most important attributes which qualifies your application every bit mature. On the other mitt, you may think, my application is working alright! Why do I need to write test-cases to verify the aforementioned?

Let me simply run y'all through a few of the issues that you may face if yous don't take proper exam-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, in that location is a lot more adventure that the feature you were working on was hindered by your partners' feature changes. These ii features may be completely different from one another, but it might cause your feature to neglect unreasonably. Subsequently, to find the problems and fixing information technology, is such an overhead. If you accept proper test-cases in identify for your feature, the proximity of finding the bug is easy, reducing your precious time.
You might lose control of your application. Day past day, your product volition receive a lot of requirements and changes. Your awarding volition grow enormously. Even a single problems in your lawmaking can cause multiple failures and a hell lot of confusion. By writing exam-cases, you will know every change that is happening in your organisation. You will exist enlightened 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 outset writing your exam-cases maybe you could follow a certain methodology which may ease your manner of writing exam-cases. I've encountered a few of those when I started writing test-cases, let me chart it down in points.

When you offset developing a piece of code, always start with your test class. Brand sure that you have a very basic runnable code in your master course and cheque for a call from your test form. If you tin can exercise information technology then you are done with your outset step.
Always be negative. That's correct, you heard me correct. Be negative with your examination-cases. Don't go looking for a successful examination run, it may crusade a problem in the later stage. Write test-cases to brand your system/characteristic to fail. Later on, start to refactor your code to counter this failure. In this manner, you can ensure that your under-developing code is unbreakable. For instance, allow's say I have a characteristic to develop which will get me a ready of registered users between two given timestamps. I would showtime by providing invalid inputs (Say, invalid date-time format) to my organisation and bank check where it fails (If refactor is required, I will have to piece of work on it). Some of these failures might cascade to your arrangement failure. Now you lot have encountered a serious effect without a Product push. In this way, y'all ensure your clients that you have a loftier availability awarding that doesn't pause for any mistake that is provided at the client's end.
Effort figuring out multiple scenarios for a single code flow. Try to write test-cases for all those scenarios. It makes your system robust. Endeavor roofing exceptions and all valid/invalid flows.
Information technology's always said that a good, mature application should have a coverage > 90%. Coverage as a whole depends on a few factors; # of lines and # of conditions or branches. Total coverage = (# of lines covered + (# of branches covered)*2)/ Total # of lines . The number " ii " here is because of each IF and ELSE cake. By covering near branches yous should be able to comprehend almost 90% of your total code. These two factors are the bones blocks for your test coverage.
Usage of mocks is always important when you write test-cases. Mock a service when it's required to render a set of test data that y'all need to examination your significant code.I accept seen people using Reflections in Coffee to set or test private fields. Avoid reflections to exam or fix your private members. By using reflections you are defying the sole purpose of a private body. Instead, load a test context during runtime which will supply data to your private fields.

I approximate I have covered the most bones details that nosotros should be aware of when test-cases are written. Every bit mentioned in the earlier quote, a production without unit testing is untrustworthy and vulnerable to all sorts of complications.

A robust code is the one that is unbreakable and has high availability during all circumstances. Speaking of high availability, for my side by side article I'll write up about the necessary resiliency strategies for architecture to ensure high availability and fault tolerance in your organisation.

Let's start writing test-cases with a mindset that it'south not just a function of quality testing, only it'southward an important office of robust evolution.

Thanks anybody for reading till the terminate. I hope it is a useful article.