6 practical tips to improve your Salesforce testing
Jason Mann on May 20th 2016
Testing your code to ensure it’s working correctly is a core tenet of good development. Good tests protect your development investment, provide the confidence to make changes safely and quickly, and help enforce business requirements.
Writing tests that get you to the magic 75% code coverage requirement is easy, but writing great tests that help protect you as you work is a real skill. In our recent webinar, we discussed why and how we test in Salesforce, and demonstrated 6 practical tips to help you write great tests that don’t become a maintenance headache.
6 practical tips for better Salesforce tests
Here are our 6 tips for Salesforce testing, taken from the webinar:
1. Isolation: run your tests with
Good unit tests interact with the smallest amount of code possible. Isolating your tests ensures they're only interacting with data that’s relevant to that specific test. By explicitly setting
false, you'll ensure your tests won’t be affected by data changing within your org. This has only recently become the default for Salesforce tests, but it’s still good practice to call it out so anyone else reading your test will know the constraints applied.
2. Arrange - Act - Assert
This is good practice for unit tests on all platforms, but is even more important in Salesforce. Start by arranging anything you need for your test. This can involve preparing test data. It's often a good idea to pull this into a separate method, as it helps keep your test compact and easy to read. Next, you act, executing your business rules or logic against the things you’ve arranged. Finally, all good tests should assert their results to check the outcome. A test that does not assert the result is not a test at all.
3. Run tests as real user profiles
By default, Salesforce tests run at a system level and have visibility into all org properties and configurations. Make sure some tests run using real user profiles, to check that the test is successful when constrained by their permissions.
If you have a large number of tests, running them can be quite compute intensive. Salesforce enforces certain governor limits on your activity to limit performance degradation. Using
Test.startTest() gives you a new set of governor limits for the act stage of your test.
Test.stopTest() then allows you to return to your previous governor limits. It also causes any asynchronous code queued up during your act stage to execute before the assert stage. For example, it allows you to test
@future methods to check they are working as expected.
5. Exercise bulk trigger functionality
Aim to have at least one test per trigger that calls more than one object - ideally around 10-20 objects. This is not to test the limits of how many objects can be called, but to test that calling the trigger with multiple objects works. Don’t add too many objects, as Sandboxes tend to have limited performance and can end up timing out, causing tests to fail (even if that same trigger would run perfectly on your Production instance).
6. Automate your test execution
Once you’ve got great unit tests in place, it’s important to run them on a regular basis. Beyond providing an ongoing awareness of the health of your orgs, regular testing allows you to find and fix silent test failures before they become deployment blockers.
The free test runner from Gearset allows you to automate your unit tests in a few clicks. Get daily reports of test status, and full debugging information for any failures. You can also track your code coverage over time. Best of all, it’s totally free. Simply follow these three steps:
- Log into Gearset using the secure OAuth process and your existing Salesforce credentials
- Authorize the orgs you want to monitor
- Create a test job from the
Want more information on testing?
For more information on the importance and benefits of testing, read our previous blog posts on why running tests is important, and how to implement test automation, or watch the full webinar recording on our YouTube channel (approx. 25 minutes).