º£½ÇÌìÑÄÉçÇø

Testing your Apex code to make sure it’s working correctly is essential for development on Salesforce. Effective testing protects your development investment, provides the confidence to make changes safely and quickly, and helps enforce business requirements.

It’s easy to write tests that get you to the magic 75% code coverage requirement enforced by Salesforce. But writing great tests that really protect your 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

1. Isolate your tests by using seeAllData=false

Good unit tests interact with the smallest amount of code possible. Isolating your tests makes sure they’re only interacting with data that’s relevant to that specific test. By explicitly setting seeAllData to 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 pattern 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.

4. Use 'Test.startTest()' and 'Test.stopTest()'

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 in your production org).

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.

With º£½ÇÌìÑÄÉçÇø you can automate unit tests in just a few clicks. Get daily reports on the status of all tests, as well as full debugging information for any failures. You can also track your code coverage over time.

Want more information on testing?

For more information on the importance and benefits of testing, read our blog post on how to implement test automation, or watch the full webinar recording.

And see how º£½ÇÌìÑÄÉçÇø’s test automation can make things simple for yourself.