Spread the love

This article is actually a repost from a buddy I came across online.

I read his articles on LinkedIn by chance and I really appreciated the easy way he writes and how he delivers important Salesforce concepts.

I choose an article about Apex Test Coverage… but before going on the article…
…please take a moment to hail our beloved lord the deployment fish!

The guest blogger

Vladimir Egikyan is a SFDC developer since 2010. Most of his career he worked for technical services providing company in Israel. During that time he helped to implement business of various companies, among which are ZIM Integrated Shipping Services, Bank Leumi.
In the latest three years he works as in-house developer and sharpen his architect skills. Though he is officially certified only as Developer… yet 😉

Writing good Apex Tests is a key to successful developing. There is a huge list of best practices and recommendations, that you can find in Salesforce documentation. Following them all, is what every developer should aim to do. Over years of developing on Salesforce, I learnt that code coverage is not what really matters…

How can that be?

Well, your coverage will raise by itself if you mind checking what your class or trigger has to do and what results you expect. Having said that, the most important thing that your test class has to do is to use System.assert methods to prove that code behaves properly. This will keep you on the safe side from any unintentional mistakes, changes in business requirements and eventually will save time and money on development process.

Okay, let’s take a look at the example:

TVRemoteControl class describes remote controls that can increase and decrease volume in scale 0-50 and have simple menu text.

Corresponding test class would contain call for each of class’ function:

TVRemoteControlTest covers the TVRemoteControl by 86% which is more than allowed minimum of 75% and these classes will deploy to production.

First and obvious defect of the test class is that it does not test if code will properly handle changing the volume beyond limits. The most important is we have to test that we get expected results in any possible use case. Our applications are almost never finished: business requirements constantly change. Besides that, we are all human and we always can make mistakes and test class is a tool that can help us to correct possible mistakes in time and that happens quite a lot.

Let’s see the better version of the test class.

This version of test class contains checking for going out of boundaries and also in each test method implements different use case and uses System.assert methods to make sure that class is performing the expected logic.

The given example is simple, but do not underestimate the importance of using assertion methods. Business logic in real life is way more complex then tv remote control, keep using these methods and you will be surprised how much time it saves for future technical support.