Application Test Execution
Application Test Execution is the Salesforce Setup page that lets administrators and developers run application-level test suites, view results, and monitor progress for Apex tests organised at the application or package level.
Definition
Application Test Execution is the Salesforce Setup page that lets administrators and developers run application-level test suites, view results, and monitor progress for Apex tests organised at the application or package level. It lives at Setup, Custom Code, Application Test Execution, alongside the related Application Test History page. The surface is closely related to Apex Test Execution but scopes runs to bundles of test classes grouped by app, namespace, or test suite. The grouping is most useful for managed-package developers and large internal teams whose code base is too big to run as a single undifferentiated set.
The page exposes the same underlying Apex Test Framework that powers all Salesforce testing. Tests run asynchronously, write ApexTestResult rows, and contribute to the org's code coverage. The distinction is the unit of selection: Apex Test Execution lets users pick individual classes and methods; Application Test Execution lets users launch a whole application or test suite in one click and review the aggregate result. ISVs use it to validate a managed package before a release. Internal teams use it to validate a single bounded subsystem without paying the cost of running every test in the org.
How Application Test Execution fits the broader Apex testing surface
Application versus Apex Test Execution
Apex Test Execution exposes a flat list of every test class and method. Application Test Execution adds a higher unit of selection: pick the application or test suite, run all its tests as one logical run. The user does not have to know every class by name. The result aggregates inside the same ApexTestRunResult and ApexTestResult records as any other run.
Test Suites as the grouping primitive
Test Suites are user-defined groupings of test classes. Setup, Custom Code, Apex Test Suites lets admins create suites like Sales Cloud Smoke or Service Cloud Regression. Application Test Execution launches a suite in one click and runs every member class. Suites are mutable; classes can be added or removed without rebuilding the suite.
Managed-package and namespace runs
ISVs commonly use Application Test Execution to run tests scoped to their managed-package namespace. This isolates the package's tests from the subscriber's local tests. The same pattern works for large internal orgs with logical sub-applications.
Async execution and progress monitoring
Runs execute asynchronously. The page shows progress (test classes processed, methods passed and failed) and refreshes as the run continues. Failed methods link to ApexTestResult detail pages with full stack traces. Completed runs roll up into the Application Test History page for later inspection.
Coverage versus pass rate
Application runs report two distinct metrics. Pass rate is the percentage of methods that succeeded. Code coverage is the percentage of underlying production code (triggers and classes) that the tests touched. Both matter; production deploys gate on 75 percent overall coverage, not on suite-level coverage.
When to use it versus CLI or Developer Console
Application Test Execution is the right tool for ad hoc Setup-driven runs scoped to a logical bundle. The Salesforce CLI handles automated pipeline runs. Developer Console offers richer log analysis during active debugging. Most teams use all three at different moments in the development lifecycle.
Limits and retention
The Apex Test Framework retains run results for a rolling window. Long-term retention requires copying ApexTestResult rows to a custom object on a schedule. Application Test Execution itself is a UI surface; the underlying data lives in standard objects and respects standard retention.
Common pitfalls
Three pitfalls recur. Forgetting to maintain Test Suites turns them into stale aliases. Running suites with data-shared tests under parallel execution triggers intermittent failures. Treating suite pass rate as deploy readiness ignores the 75 percent coverage gate that still applies at production deploy time.
How to run an Application-level test suite
The page itself is a thin wrapper around the Apex Test Framework. Most of the value comes from maintaining Test Suites that map to real subsystems and running them at the right moments.
- Define Test Suites
Setup, Custom Code, Apex Test Suites. Create suites that map to real subsystems: Sales Cloud Smoke, Service Cloud Regression, Integration Layer, and so on.
- Open Application Test Execution
Setup, Custom Code, Application Test Execution. Click Select Suites and choose the suite you want to run.
- Submit and watch progress
Click Run. The page polls and updates pass/fail counts per class. The run is async, so walking away is fine.
- Drill into failures
Click any failed class to view the offending method, the assertion message, and the stack trace. Cross-reference with Apex Jobs if the run involved async paths.
- Review history and trend
Open Application Test History to compare the latest run against prior runs. Sustained pass-rate or coverage drops surface trends that single-run inspection misses.
- Suite pass rate is not deploy readiness. The 75 percent overall coverage rule still applies at production deploy time.
- Stale suites are misleading. Tests added to the codebase do not automatically join a suite; maintenance matters.
- Parallel execution can break tests that share data. Fix the data isolation; disabling parallel testing globally is a heavy hammer.
- Retention is short. Export ApexTestResult rows weekly for any trend analysis longer than a few weeks.
Trust & references
Cross-checked against the following references.
- Apex Test ExecutionSalesforce Help
- Apex TestingApex Developer Guide
Straight from the source - Salesforce's reference material on Application Test Execution.
- Apex Test SuitesApex Developer Guide
Hands-on resources to go deeper on Application 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 skill set is typically needed to work with Application Test Execution?
Q2. What is a Governor Limit in the context of Application Test Execution?
Q3. What is required before deploying Application Test Execution-related code to production?
Discussion
Loading discussion…