Regression Testing
Regression Testing in Salesforce is the practice of running existing tests after a change to confirm the change has not broken previously working features.
Definition
Regression Testing in Salesforce is the practice of running existing tests after a change to confirm the change has not broken previously working features. The change can be a code deploy, a configuration update, a package install, or a platform-pushed release upgrade. The tests can be Apex unit tests, automated UI scripts, or manual checklists run by QA.
Regression testing is enforced by the platform in one specific case: deploying Apex code to production. Salesforce requires that at least 75 percent of Apex lines across the org are covered by passing tests before any code deploy succeeds. The 75 percent rule is the floor, not the goal; mature teams target 85 to 95 percent coverage with assertions that catch real behaviour, not just lines that ran without throwing.
How regression testing keeps Salesforce changes from breaking what already works
What counts as a regression in a Salesforce org
A regression is any behaviour change that breaks something that previously worked. In Salesforce, regressions show up in many forms: a flow that stops firing on the right records after a validation rule change, an Apex trigger that silently swallows an error after a refactor, a Lightning component that no longer renders on mobile after a CSS update, a roll-up summary field that returns the wrong total after a sharing rule change. Regression testing catches these before they reach production users. The discipline is to run the test suite for every change, large or small, and to treat any new failure as a deploy blocker until triaged.
Apex tests as the foundation of Salesforce regression testing
Apex test classes are the backbone of any Salesforce regression suite. They run in the platform's test runner against either real org data or in-memory test data created by the test setup methods. Each test method asserts that a specific behaviour holds: a trigger sets the right value, a method returns the expected result, a flow handler routes the record to the right queue. Apex tests are deterministic, fast (a few seconds per method), and integrate with the platform's deploy validation. The 75 percent coverage rule applies to every Apex line in the org, not per class, so one heavily-covered class cannot offset another that has no tests.
What 75 percent code coverage actually measures
The 75 percent coverage rule counts the percentage of Apex lines that any test executed during the test run. It is a line-coverage metric, not a behaviour metric. A class with one test that calls every method once but never asserts anything will hit 100 percent line coverage and pass the deploy. The same class with no assertions will silently let bugs through. Mature teams treat the 75 percent threshold as a checkbox and focus their effort on writing meaningful assertions that verify behaviour, not on padding coverage with trivial tests that exercise lines without checking outcomes.
Sandbox refresh and the regression baseline
A regression test suite is only as good as the data it runs against. Full sandboxes with production data give the most realistic regression coverage; the trade-off is the cost (storage and license) and the refresh time (often days for very large orgs). Partial sandboxes copy a sampled slice of production. Developer Pro sandboxes are empty. The standard pattern is to refresh a full sandbox monthly or quarterly, run the regression suite against it, and use Developer Pro sandboxes for fast iterative testing on individual changes. Refresh cadence directly affects regression confidence: stale sandbox data hides bugs that production data would catch.
UI automation and the layer Apex tests cannot reach
Apex tests cannot click a button or fill a form. UI behaviour like field visibility on a page layout, conditional logic in a Lightning component, or the order of validation messages requires UI automation. The Salesforce ecosystem has several tools for this: Provar, AccelQ, Tricentis, and Selenium with the Salesforce DOM bindings. UI tests are slower than Apex tests (minutes per scenario, not seconds) and more fragile (page layout changes can break them). The pragmatic regression strategy is Apex tests for logic, UI tests for critical user paths, and manual checklists for everything else.
Release-time regression: the three Salesforce releases per year
Salesforce pushes three platform releases per year (Spring, Summer, Winter). Each release ships hundreds of platform changes and the occasional breaking change. The pre-release period is when regression suites earn their keep: Salesforce publishes the release notes weeks in advance, sandbox previews of the new release are available a month before production, and orgs that run their regression suite against the preview catch incompatibilities before the release hits production. The standard pattern is to refresh a sandbox to the preview pod, run the full regression suite, and triage any failures before the production upgrade window.
Continuous integration and the regression cadence
Mature Salesforce DX setups run regression tests on every commit. Each pull request kicks off an Apex test run in a scratch org or sandbox; the suite must pass before the change merges. UI tests typically run on a schedule (nightly or per-build) because they are too slow for per-commit execution. The cadence depends on the org's risk tolerance and tooling investment: smaller orgs may run Apex tests only at deploy time and accept the risk of catching regressions later, while larger orgs treat the pipeline as the gate and refuse to merge changes that break the regression suite.
Run a Salesforce regression suite before a production deploy
A Salesforce regression suite combines Apex tests, optional UI automation, and a sandbox to run them against. The steps below cover the most common workflow: prepare the sandbox, run the suite, triage failures, then unblock the deploy.
- Refresh the sandbox to a recent baseline
Refresh a full or partial sandbox so the regression suite runs against current data and metadata. For pre-release testing, refresh to the preview pod assignment that exposes the upcoming Salesforce release.
- Run the Apex test suite
Run All Tests in Setup, Apex Test Execution. Watch the test runner for failures and coverage drops. The Tests tab shows per-method pass/fail; the Code Coverage tab shows the lines each test touched.
- Run the UI automation suite
Trigger the UI automation tool (Provar, AccelQ, Selenium) against the sandbox. UI suites take longer to run than Apex suites; budget a few hours for a moderate-sized scenario library.
- Triage failures by impact
For every failing test, decide whether the failure points to a real regression in the change being tested or a test-maintenance issue like a stale assertion or a UI selector that no longer matches. Fix real regressions; update tests for legitimate change.
- Block the deploy or unblock
If the regression suite passes, proceed with the production deploy. If it fails, either fix the change being tested or document an accepted regression with stakeholder sign-off before deploying.
Choose between Run All Tests (slow, full coverage) and Specified Tests (faster, narrower). Run All Tests before production deploys.
Full sandbox refreshes are slow but produce realistic regression results. Partial sandboxes refresh faster but may miss data-driven bugs.
Continuous integration runs the suite on every commit; manual triggering runs on demand. CI catches regressions earlier but requires automation investment.
- 75 percent code coverage is a line-coverage metric, not a behaviour metric. Tests that hit lines without asserting outcomes pass the deploy gate but catch no real regressions. Always pair coverage with meaningful assertions.
- Apex tests cannot exercise UI behaviour like page layouts, conditional component visibility, or validation message order. UI automation is the only way to cover that layer reliably.
- Stale sandbox data hides bugs that production data would expose. Refresh sandboxes regularly and treat the freshness of the regression baseline as a leading indicator of regression quality.
Trust & references
Cross-checked against the following references.
- Apex Testing OverviewSalesforce Developers
- Code Coverage in ApexSalesforce Developers
- Create a SandboxSalesforce Help
- Release Management Decision GuideSalesforce Architects
Straight from the source - Salesforce's reference material on Regression Testing.
- Testing ApexSalesforce Developers
- View Apex Code CoverageSalesforce Help
Hands-on resources to go deeper on Regression Testing.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is Regression Testing?
Q2. Why is regression testing important?
Q3. Where should regression tests run?
Discussion
Loading discussion…