How To Write Unit Tests, Elegantly

“If you don’t like unit testing your product, most likely your customers won’t like to test it either.” — Anonymous

• 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.

What do we gain by writing test-cases?

• 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.

How to write elegant test-cases to avoid such detrimental failures?

1. When you start developing a piece of code, always start with your test class. Make sure that you have a very basic runnable code in your main class and check for a call from your test class. If you can do it then you are done with your first step.
2. Always be negative. That’s correct, you heard me right. Be negative with your test-cases. Don’t go looking for a successful test run, it may cause a problem in the later stage. Write test-cases to make your system/feature to fail. Subsequently, start to refactor your code to counter this failure. In this way, you can ensure that your under-developing code is unbreakable. For instance, let’s say I have a feature to develop which will get me a set of registered users between two given timestamps. I would start by providing invalid inputs (Say, invalid date-time format) to my system and check where it fails (If refactor is required, I will have to work on it). Some of these failures might cascade to your system failure. Now you have encountered a serious issue without a Production push. In this way, you ensure your clients that you have a high availability application that doesn’t break for any mistake that is provided at the client’s end.
3. Try figuring out multiple scenarios for a single code flow. Try to write test-cases for all those scenarios. It makes your system robust. Try covering exceptions and all valid/invalid flows.
4. It’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 “2” here is because of each IF and ELSE block. By covering most branches you should be able to cover almost 90% of your total code. These two factors are the basic blocks for your test coverage.
5. Usage of mocks is always important when you write test-cases. Mock a service when it’s required to return a set of test data that you need to test your significant code.I have seen people using Reflections in Java to set or test private fields. Avoid reflections to test or set 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.