Salesforce test automation in CI: what to run on every pull request, and what to run nightly

Short answer: on every pull request, run only the fast and deterministic checks: static analysis on the diff, LWC Jest, and a validate-only delta deployment that runs just the Apex tests covering the changed code. Push everything slow or flaky, full org test runs, UI journeys and external integrations, to a nightly job. Aim for a pull request verdict in under ten minutes, because past that people stop reading it.

What belongs on every pull request?

• Static analysis on the diff. Seconds, no org, catches the mechanical problems before a human reads the code.
• LWC Jest tests. They run off-platform in Node, so they need no org at all.
• A validate-only delta deployment against a target-shaped org, with the test level set to run only the classes that cover what changed.
• Metadata sanity checks. No unintended destructive changes, no profile or permission set entries silently disappearing.

One rule governs this list: everything on the pull request gate must be deterministic. A single flaky test teaches the team to press re-run, and a gate people re-run until it goes green is decoration.

What belongs in the nightly job?

• A full local Apex run against the integration sandbox. This is what catches the class you did not know your change touched.
• UI journeys across the core business flows.
• Integration tests that call external systems, where you cannot control latency or availability.
• A drift check between the integration org and the branch, so someone editing directly in Setup is visible the next morning.
• The org-level coverage trend, which is a report and not a gate.

Nightly failures get triaged over coffee. That is the point: they are not standing between a developer and their merge.

What should only run before a release?

• The full regression suite and any user acceptance pass.
• Performance and bulk-data tests, which need volume that a scratch org does not have.
• A validate-only deployment against production, followed by a quick deploy so the release window is not spent waiting for tests to run.

How do Salesforce's test levels map onto this?

Four levels, and the choice per stage is most of the design (Metadata API guide).

• NoTestRun: fine inside a scratch org, never on a path to production.
• RunSpecifiedTests: your pull request gate. One catch worth knowing: at this level each class and trigger in the deployment package must reach 75% coverage individually, computed per component rather than org-wide (Salesforce docs).
• RunLocalTests: everything except managed package tests. This is what a production deployment containing Apex runs by default.
• RunAllTestsInOrg: adds managed package tests. Rarely what you want, and slow.

The platform rules underneath do not change: at least 75% of your Apex must be covered to deploy to production, every trigger needs at least one line of coverage, and every test that executes has to pass, whatever the coverage number says (Salesforce Help).

How do you keep the pull request loop under ten minutes?

1. Deploy the delta, not the org. Validate only what the branch changed.
2. Derive the test list. Generate the specified test classes from the changed components instead of running everything by hand-maintained list.
3. Run in parallel. Jest and static analysis should run alongside the org validation, not queue behind it.
4. Keep a warm target org. Creating and seeding an org per pull request is usually the single largest block of clock time. Use a pool or a long-lived validation sandbox.
5. Cache dependencies between runs, including the CLI and Node modules.
6. Stub or defer external calls. Anything whose response time you do not control belongs in the nightly job.
7. Measure the duration and put it somewhere visible. Pipeline runtime creeps quietly and only ever in one direction.

Where do UI tests belong?

Not on the pull request. UI tests are the slowest and the most brittle thing in a Salesforce pipeline: shadow DOM in Lightning components, generated element ids and login prompts all break selectors for reasons that have nothing to do with the change under review.

The workable placement is a small smoke set of five to ten critical journeys after merge to the integration branch, and the full suite nightly. A practical rule: if a UI test fails twice for reasons other than the product, it is a maintenance item, not a gate.

How should coverage gates be set?

• Gate the pull request on coverage of the changed code, not on the org-wide number. The org number moves slowly and hides brand new untested classes behind years of old ones.
• Keep the org-wide floor as a release gate, where it belongs.
• Do not let the percentage become the goal. Salesforce's own guidance is to cover every use case, positive and negative, bulk and single record, and let the number follow.

This guide is part of our Salesforce DevOps guides.

FAQ

How fast should a Salesforce pull request check be?

Under ten minutes end to end. Beyond that developers context-switch, stop reading the output, and the check stops changing behaviour.

Should we run all Apex tests on every pull request?

No. Run the tests covering the changed classes with RunSpecifiedTests, and keep the full local run for the nightly job and the release validation.

What coverage does Salesforce actually require?

75% of Apex org-wide to deploy to production, at least one line of coverage on every trigger, and every executed test must pass. With RunSpecifiedTests, each class and trigger in the package needs 75% on its own.

Do LWC Jest tests need a Salesforce org?

No. They run off-platform in Node, which is exactly why they belong on the pull request gate rather than in the nightly job.

Where should UI tests run?

A small smoke set after merge, the full suite nightly. Putting them on the pull request is the fastest way to teach a team to ignore a red build.