When delivering Salesforce changes, we want them to be rock solid and robust. The Change Failure Rate (CFR), one of the DORA metrics for DevOps, measures how often releases fail — a good indicator of release quality. But how do we achieve a good score? The answer lies in ensuring we test our changes thoroughly.
In this post, we’ll look at some of the essential best practices to adopt in Salesforce testing and how to implement them as a fundamental part of a DevOps strategy.
Common challenges with Salesforce testing
Salesforce testing comes with unique challenges, mostly due to the platform’s frequent updates, complex integrations, the specific data requirements needed for effective validation, and the frequency of human error.
Salesforce updates
With three major releases a year, it’s essential for teams to ensure that their existing tests remain compatible with any Salesforce platform updates, and that new features or API changes don’t disrupt workflows. But staying current with Salesforce updates can be difficult, especially without automated regression testing to catch issues early. Proper planning around new Salesforce releases is vital — this can be a good time for full system testing, in a release preview sandbox, to ensure that your implementation will be unaffected by the new version.
Third-party integrations
Third-party integrations add to the complexity of Salesforce testing. Connections to external systems, such as ERP platforms, marketing tools, or analytics services, can create dependencies that make it challenging to maintain stable, reliable testing. Small changes in one system can ripple through to affect Salesforce functionality in unexpected ways, demanding a thorough approach to integration testing to ensure end-to-end reliability. For this reason, it’s important to always test your data flows between Salesforce and third-party systems — and be mindful that this may require testing on the other apps end of things too, bringing the DevOps spirit of collaboration to the fore.
Data quality
Data quality is another critical component of successful testing, yet it’s often inconsistent in Salesforce environments. Poor data quality can lead to unreliable test results, masking potential issues that only emerge in production. Realistic, high-quality test data is vital to accurately reflect how the platform will behave in real-world use cases. Privacy and security concerns also require you to handle test data carefully, particularly when dealing with sensitive information. Data masking and other anonymization techniques can help maintain compliance while allowing realistic testing.
Human error
The people element is a key factor — human error is an ongoing challenge, especially in manual testing processes. Although this manual testing is sometimes necessary for complex workflows, it’s prone to inconsistencies. Combining automation for repetitive, high-impact tests with standardized test scripts for manual procedures can reduce this risk, providing a more dependable approach to maintaining quality.
In the face of these challenges, let’s now look at some of the steps we can take to elevate our Salesforce testing.
Test early, test often: the different types of Salesforce testing
If production is the first time you’re hearing about a bug or issue in your Salesforce releases, then finding and fixing problems becomes a lot slower and more expensive. Testing earlier in the software development lifecycle, or “shifting left”, helps prevent those pesky bugs from slipping through from environment to environment.
This doesn’t mean that the development phase is the only point you test though — testing should be carried out throughout the whole development lifecycle. There are many different types of testing to consider as part of delivering a successful project. Here are a few:
- Functional testing. Confirming that the changes work as intended without errors
- Unit testing. Not just making sure that you meet Salesforce’s mandatory 75% code coverage requirement, but validating the results of your changes
- Integration testing. Ensuring any new changes play well with other systems
- Regression testing. Making sure that anything you introduce hasn’t broken existing functionality. Not every part of the system requires a complete system test each time, so prioritize high-impact and high-risk areas to help streamline the testing process
- UI testing. Checking the user interface to verify elements display correctly and interactions perform as intended
- User acceptance testing. Checking that the end users’ needs have been met in line with their acceptance criteria
- Large volume testing. Validating your changes will scale in the face of large data volumes
- Performance testing. Assessing system responsiveness and stability under heavy workloads
- Smoke testing. Running basic tests to verify that core functions work properly before deeper testing begins
- Stress testing. Pushing the system beyond normal limits to evaluate its behavior and stability under extreme conditions
- Security testing. Identifying vulnerabilities to ensure data protection and compliance with security standards
By adopting these various types of testing throughout your DevOps process as early as possible, through automation, you will find any issues sooner and fix them more quickly.
Apex testing best practices
While Apex tests are mandatory, it doesn’t mean you should scrape by with minimum code coverage or poorly written tests. Let’s look at some best practices for Apex testing.
Don’t rely on existing data
Apex tests shouldn’t use real data from your Salesforce environment — not only is this bad practice, but in a lot of cases, data in your sandbox doesn’t exist in other test environments, or it has different values or IDs to your development sandbox. The default for Apex tests is that this data isn’t visible, but if you want to be explicit about it, tagging your test classes with SeeAllData=false will make it very clear. The test data and objects you need for your testing should be created and populated in their own TestSetup annotated methods.
Check the results
Executing the tests is only half of the story — if you’re not checking the results against expectations, you’re not truly testing that things are working as expected. Ensure that you make good use of the various Assert methods in Apex to check that values returned are correct — or incorrect, as we’ll see shortly…
Look for positive and negative paths
Good testing includes checking what happens when things go wrong. Be mindful not to only check the “happy path” where all data is present and correct. You should test (and assert!) scenarios when things aren’t correct, and how the system behaves accordingly. For example, what if a value supplied is 0, or less than 0, or greater than you expected — or not even a number at all! Make sure that your test cases cover multiple test scenarios.
Think big, test for scale
In Salesforce, data doesn’t always come in one record at a time. Your Apex tests should be written in a way that checks what happens when you receive one record, or many records in a collection. What happens when you get more records than can be handled in one transaction? Apex testing will give you that answer, and allow you to adjust your code where needed to ensure smooth operations.
Don’t assume everyone is an admin
Apex tests typically run in a system context, but in day-to-day use of Salesforce your users will have a range of permissions, which may or may not affect how things run. To ensure you’ve covered these eventualities, you should run your tests as a variety of users or profiles (again, making sure you check the outcomes with assertions) by making good use of the Apex runAs method.
Push the limits
Salesforce comes with its own governor limits that ensure you don’t cause performance issues in the system. Apex unit tests are not exempt from these limits, but there are some steps we can take to help our testing. Wrapping our test methods in a test.startTest() and test.stopTest() pair allows any code executed between these two statements to have their own fresh set of governor limits. This allows us room to breathe after setting up the test conditions ahead of the actual functionality we want to test.
Testing isn’t just about Apex code
While we’ve looked at some of the vital elements of Apex testing in this post, it’s important to remember that not all Salesforce changes come in the form of Apex code. The same testing rigor should be applied to everything we deploy — Flows, Lightning Web Components and even config changes to a degree. If you’re changing something that affects how the system functions, or how users interact with it, then testing should definitely be part of your process.
Flow testing
Salesforce Flows are a powerful option for low/no-code development on the Salesforce platform. As they have features comparable to code in their ability to change your business logic in Salesforce, Flows should definitely be considered in your testing.
The native Salesforce tools for testing your Flows allow you to execute a debug run of your flow, and then save it as a test, with the data and options you supplied. But there are a few drawbacks to this approach:
- You would need to build and execute multiple debug runs to cover each scenario you need to test.
- This approach uses real data from your Salesforce org to work with — something we already identified as a bad practice when looking at Apex tests.
- Flow tests are only available for Record-Triggered Flows.
- Flow tests cannot be automatically executed as part of a deployment or pipeline.
- These types of Flow tests do not count to your test coverage metrics.
Current best practice remains to test your flows with Apex code, much like you would with testing Apex itself. You can launch Flows from Apex and validate the results in your test environment. Additionally, you can query the FlowTestCoverage object to check your metrics.
Lightning Web Component (LWC) testing
As Lightning Web Components are based on modern JavaScript architecture, we can adopt the testing approaches that come from the wider JavaScript development community. For practical reasons, Salesforce recommends the use of the Jest tool for LWC testing.
We won’t be looking at the specifics of writing Jest tests in this post, but the fundamentals of Salesforce testing still apply — test early and often, test positive and negative paths, and test for scale. Much like the other types of tests, LWC tests should be part of your overall Salesforce testing strategy and included in your CI/CD automation pipelines. This will help keep your Change Failure Rate down and your developer happiness up.
Salesforce test automation
Once you’ve got great tests in place, it’s important to run them on a regular basis with test automation tools. Beyond providing an ongoing awareness of the health of your orgs, when you automate Salesforce testing, you can find and fix silent test failures before they become deployment blockers.
With Gearset 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 track your code coverage over time and, as Gearset integrates with a variety of Salesforce testing tools, automate your testing process even further.
Automated testing gives you the peace of mind that your changes are of a consistent quality on every release, without the time-consuming overhead of manual testing.
Want to learn more about testing?
Want to delve deeper into Salesforce testing and Gearset’s test automation? Learn more in the free testing course on DevOps Launchpad or speak to one of our experts about how test automation with Gearset can optimize your DevOps delivery.
