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 admin, 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 now filled with corrupted data. “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?”
Scheduled unit test settings in the Lucidware Solutions admin console:
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 they can be a powerful way to ensure your Salesforce data maintains its integrity.
Unit tests are typically 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 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 them so that they can continue to provide a level of confidence in data integrity and the “correctness” of your implementation.
These unit tests exist in your production Salesforce org, and there are several different ways to invoke them. Each of these ways 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.
At Lucidware Solutions, we recommend that clients execute all unit tests in their production org each night. Any failures are logged and emailed to the development team for analysis. 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.
Unfortunately, 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. That’s very cheap considering the benefits such a process provides. The following are the steps in creating an automated unit test strategy.
- Create custom Apex classes for launching unit tests and analyzing the results. Lucidware Solutions’s has a home-baked solution, but similar functionality is now provided by GearSet, Copado, and other 3rd part packages.
- Create scheduled Apex jobs to execute the tests and analyze the results.
- Wait for the automated test results to roll into your inbox.
With the FC library, you can:
- schedule regular test runs
- run all Apex unit tests or specify a class prefix
- optionally run tests in 3rd party packages
- specify a target coverage percentage for reporting
- email test results to multiple recipients
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.
We need to mention another large caveat: the usefulness of your automated test execution is limited by the quality of the unit tests. In our experience, developers often skimp on unit test quality for the reasons given above – no one sees them or evaluates their usefulness. Here’s an excellent checklist for reviewing unit tests.
As custom code is added to your implementation, insist on great unit tests. Automating unit test runs will then reap enormous benefits in your organization!