Here’s an experience that’s familiar to many Salesforce administrators. One day, a user reports a problem she is seeing in your Salesforce instance. As the Salesforce administrator, you are asked to investigate the problem and determine the extent of the damage and the solution. Upon investigation, you realize that the problem has existed for a very long time and your Salesforce instance is filled with data integrity issues. “Why wasn’t I notified of this earlier?” you ask. “How could this problem have gone on for so long without coming to my attention?”
One of the simplest things you can do to maintain the quality of your Salesforce implementation is to run unit tests and fix any failures. Unit tests are written in Apex and usually are never seen or noticed by anyone except the developer who wrote them but, believe me, they can be a powerful way to ensure your Salesforce data maintains its integrity.
Unit tests are written by developers when creating custom features for your organization. Good unit tests will exercise many of the features of your custom implementation. Custom code cannot be deployed unless all unit tests succeed, and Salesforce requires that all code be unit tested with a minimum 75% coverage. While developing a solution, this provides a minimal level of assurance that code is well behaved.
But over time, tests may “break” due to any number of reasons. Here are some of the most common:
- A field on an object is made “required” if a unit test creates instances of that object and doesn’t include the now required field, the test will fail.
- A new validation rule restricts the values allowed for a custom field.
- A custom app is installed that changes the environment significantly.
- A trigger is deactivated.
A failing unit test may or may not indicate actual problems for your organization, but it’s always a good idea to fix it so that it can continue to provide a level of confidence in data integrity and the “correctness” of your implementation.
There are several different ways to invoke unit tests. Each of them is covered in detail by this Salesforce document. The method used is not important. What’s critical is that you run them all on a regular basis. Unfortunately, Salesforce hasn’t yet provided a simple way to do this. I imagine they will in the near future.
At Cloud for Good, we execute all unit tests in our production org each night. Any failures are logged and emailed to the development team for analysis. We set up a similar process for many of our clients during custom code development. These automated unit test runs are essential in helping us to find problems early and fix them before they lead to client frustration and data integrity problems.
Here’s where things get a little technical. On the positive side, the process below takes just a couple hours of custom development time and setup. The following are the steps to create an automated unit test strategy.
- Create custom Apex classes for launching unit tests and analyzing the results. Cloud for Good’s solution is loosely based on an excellent article by Luke Freeland.
- Create scheduled Apex jobs to execute the tests and analyze the results.
- Wait for the automated test results to roll into your inbox.
If you’ve got everything set up correctly, you should start seeing an email each day with a report of the unit test execution. When a failure is reported, waste no time in getting a developer to analyze the problem and fix it right away.
I have to mention another large caveat as well. The usefulness of your automated test execution is limited by the quality of the unit tests. In my experience, developers often skimp on unit test quality for the reasons given above – no one sees them or evaluates their usefulness. As custom code is added to your implementation, insist your developers use best practices to great unit tests. Automating unit test runs will then reap enormous benefits in your organization!
