Apex Test Execution
Apex Test Execution is the Salesforce Setup page that lets administrators and developers launch Apex unit-test runs interactively, monitor progress, and inspect results.
Definition
Apex Test Execution is the Salesforce Setup page that lets administrators and developers launch Apex unit-test runs interactively, monitor progress, and inspect results. It lives at Setup, Custom Code, Apex Test Execution. The page is one of three primary surfaces for running Apex tests in the platform. The Developer Console offers more verbose output and richer parallel runs, and the Salesforce CLI is the path most production CI/CD pipelines use. Apex Test Execution is the lowest-friction surface inside Setup itself, and the one new administrators tend to reach for first.
The page lets users select one or many test classes, choose which methods inside each class to run, and submit the run. Tests execute asynchronously. The page tracks progress, shows pass/fail counts per class, and links into the underlying ApexTestResult records for failed methods. The same data flows into the Apex Test History page for trend analysis across recent runs. For day-to-day developer work, Developer Console and the CLI win on UX; for ad hoc runs and quick validations, Apex Test Execution is the right tool inside Setup itself.
How Apex Test Execution fits the broader testing surface
The three execution surfaces
Apex Test Execution lives inside Setup. The Developer Console offers a richer Test menu with parallel runs, test logs, and the ability to drill into the Apex stack trace inline. The Salesforce CLI runs tests from the command line via sf apex run test, with output that fits into CI/CD pipelines. All three call the same underlying Apex Test Framework and produce the same ApexTestResult rows. The choice is about workflow, not capability.
Test class and method selection
The page lists every test class in the org. Users can select all of them, a few, or specific test methods inside a class. Selecting a subset is the fast path for validating a recent code change without paying the cost of the whole suite. The selection UI also supports namespace filtering for orgs with multiple managed packages installed.
Asynchronous execution and tracking
Submitting a test run queues an asynchronous Apex job. The page shows the progress bar and updates in near-real time. Once finished, classes show pass and fail counts, and failed methods link to the failure detail. The async model means submitting a large run and walking away is fine; the results stay accessible afterwards.
ApexTestResult and ApexTestRunResult records
Every test method run produces an ApexTestResult row containing the outcome, the stack trace if it failed, the time elapsed, and the running user. Every test run produces an ApexTestRunResult row that aggregates the methods. Both objects are queryable via SOQL, which is how custom dashboards expose test trend data alongside the standard Setup view.
Test history retention
The Apex Test History link from Apex Test Execution shows the recent test runs in the org. Salesforce keeps the history for a rolling window (weeks, not forever). Production teams that need longer-term trend data export the ApexTestResult rows to an external system or a Salesforce custom object on a schedule.
Code coverage requirements
Apex tests must cover at least 75 percent of Apex code in the org before a production deploy succeeds. The percentage is calculated across all triggers and classes deployed in the change set. Apex Test Execution surfaces overall coverage and per-class coverage after a run. Failing the 75 percent gate is the most common production-deploy failure mode and the first thing to check when a deploy fails on test coverage.
Test data isolation and @testSetup
Apex tests run with isolated data by default. Each test method gets a clean DML slate unless the developer opts into seeing org data with @isTest(SeeAllData=true). The @testSetup annotation creates shared data once per class, reducing duplication. Apex Test Execution does not change these defaults; they are class-level developer choices that affect what data the test sees.
When to use each surface
Apex Test Execution is the right tool for: validating after a deploy, running a quick suite from an admin's seat, or doing one-off coverage spot checks. Developer Console is better for active development, log analysis, and parallel work. The CLI is the path for any CI/CD pipeline. A single team rarely uses only one surface; each fits a different moment in the lifecycle.
How to run Apex tests from the Setup page
The page is straightforward. Knowing which subset to run, how to read the results, and when to fall back to Developer Console or CLI is the operational knowledge.
- Open Apex Test Execution
Setup, Custom Code, Apex Test Execution. Click Select Tests to choose what to run.
- Select the right scope
For a quick validation, pick the specific test class for the code that changed. For pre-production validation, select all classes. Avoid running the whole suite for every small change; it wastes async capacity.
- Submit and watch progress
Click Run. The page polls and updates the pass/fail counts per class. Walking away is fine; the run continues asynchronously.
- Drill into failures
Click any failed class to see the failed method, the assertion message, and the stack trace. Cross-reference with Apex Jobs if the failure looks async-related.
- Check code coverage
After the run, open the Code Coverage page to confirm the org meets the 75 percent threshold before any production deploy.
- Test history retention is weeks, not forever. Long-term trend analysis requires exporting ApexTestResult rows.
- The 75 percent coverage rule applies at deploy time. Tests that exist but cover the wrong code do not help; coverage is per-class.
- Tests run async. Submitting a run does not block; come back later or watch the page.
- Parallel testing defaults to on. Tests that share data (a singleton account record, an in-memory counter) can fail intermittently. The fix is data isolation, not disabling parallel testing.
Trust & references
Cross-checked against the following references.
- Running Apex TestsApex Developer Guide
- Apex Test Execution PageSalesforce Help
Straight from the source - Salesforce's reference material on Apex Test Execution.
- Apex TestingApex Developer Guide
Hands-on resources to go deeper on Apex Test Execution.
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 Apex Test Execution?
Q2. What is the minimum code coverage required to deploy Apex to production?
Q3. Which of these can you do from Apex Test Execution?
Discussion
Loading discussion…