can·dy cov·er·age
Just like eating too much candy can sabotage an otherwise healthy person, allowing too much candy code coverage in your salesforce org can cause problems down the line and we’re not just talking about a “Baby Ruth” appearing in your pool here.
As a Salesforce user or admin, you may be aware that Salesforce has standards in place that require developers to cover any custom code written with code coverage (implemented by unit tests). The minimum amount of coverage allowed is 75%, otherwise developers cannot migrate any code changes to another org.
The thinking is, all functionality created by code should be well thought out and developers must prepare not only for the best-case scenario but handle situations where the code fails. Any good developer who wants a “Pay Day” will write tests that cover all expected scenarios, both good and bad.
Side note, I hope you’re getting my candy name easter egg references in this article.
Benefits of Code Coverage
So, what are the benefits of writing good unit tests for your code coverage? Some of these benefits not only impact your Salesforce users immediately but they can also come into play years down the road, long after your developers have moved on to other projects or worse, they are no longer part of the organization.
The biggest benefit you’ll get by writing good unit tests is it can lead to better architected solutions by your developers and less production support issues. Writing unit tests is a good mental exercise that helps developers think of not only the most common situations your code might encounter but also some other scenarios that could otherwise lead to errors and lost productivity from your Salesforce users.
Unit tests are also a form of documentation. Whether you have in-house developers or you hire a consulting firm like us, unit tests also act as a form of documentation that can be extremely useful down the line.
One way or another, developers move on to different things but you’ll always need the ability to quickly know what the purpose of your custom code does and how it works. What you’re trying to avoid here is a developer looking at code written a year ago and thinking “Whatchamacallit”? Instead you want your units tests sitting there to either show the original intent of the code and you also want the tests to immediately tell other developers that changing the original code is going to cause certain side effects because those units tests will fail with an explanation of why they failed.
What is Candy Coverage
So with all of the above said, what exactly is candy coverage? Candy coverage is a term we use where a developer manipulates the unit tests to appear like you’re getting code coverage but what they’re in fact doing is just executing code in the unit test without really testing any scenarios. This is actually easier than you think and frankly as a consultant, we see it more often than not.
Just like eating too much candy can eventually lead to problems with your health down the line, having too much candy coverage in your org can lead to big problems in your organization’s future. You won’t see the symptoms overnight but make no mistake about it, eating too many “Snickers” in the form of candy-covered unit tests is going to cost you over time.
What are the symptoms of this unhealthy diet?
First, you can start with bugs being introduced into your production code that impact your business users from doing their daily job. This is going to be the most immediate symptom you’ll notice.
Second, bringing in new developers is going to cost you extra time and money because you don’t have unit tests to help document the thought process for the functionality. It’s also going to cost time and money because any reputable developer is going to try and correct the poor unit tests he or she encounters as they change existing code.
Finally, remember that Salesforce has 3 releases every year. The releases start in your sandbox and then are eventually migrated to your production orgs. It’s good practice to run your unit tests in the sandbox org to test the new update.
If you have candy coverage, guess what? Running your candy covered unit tests is probably not going to give you any warning of upcoming problems.
Why Does Candy Coverage Happen?
From the years of consulting we have seen the top 3 reasons candy coverage exists.
- The project does not allow for enough time to write proper unit tests
- The developer knows how to write unit tests but did not write proper unit tests because it’s always easier and faster to write tests that don’t verify functionality
- The developer does not have the skills and experience to know how to write a proper unit test and needs to learn
Conclusion
Unit test coverage is often an activity that gets placed on the back burner. It doesn’t get the attention it truly deserves and if left ignored, your “100 Grand” project can lead to a project that is considered a “Butterfingers” instead. You may not feel the impact of poorly written unit tests immediately but make no mistake, it can lead to long term impacts and wasted money.
Unit test coverage is not just a percentage that a developer can spout off as they proudly announce they have 90% coverage. The coverage is fine but what really matters is the scenarios the unit tests are actually testing. In our next blog entry, we’ll explore ways your organization can help identify and correct your unhealthy candy diet.