Application Test Execution
Application Test Execution is the Salesforce Setup page where administrators and developers run Apex tests and automated flow tests, then watch the results as they come back.
Definition
Application Test Execution is the Salesforce Setup page where administrators and developers run Apex tests and automated flow tests, then watch the results as they come back. You reach it from Setup by typing "Application" in the Quick Find box and selecting Application Test Execution. From there you pick which tests to run, launch them, and review pass and fail counts plus code coverage in one place.
This page is the current home for declarative test runs in an org. It replaced the older Apex Test Execution page, so the name changed but the job stayed the same. The notable upgrade is scope. The page now runs both Apex unit tests and flow tests created with automated flow testing in Flow Builder, which the old Apex-only page could not do. A companion page, Application Test History, keeps the record of past runs for later review.
How Application Test Execution Works in an Org
From Apex Test Execution to Application Test Execution
For years the Setup page that ran tests was called Apex Test Execution, paired with Apex Test History. Salesforce renamed these to Application Test Execution and Application Test History. The rename was not cosmetic. The old page ran Apex tests only. The new page runs Apex tests and automated flow tests in the same interface, which matches how teams now build logic across both pro-code and low-code. If you have older runbooks or training docs that point people to "Apex Test Execution," update them. The Quick Find term is now "Application," and the menu entry reads Application Test Execution. The underlying Apex test framework did not change. Tests still run asynchronously, still write standard result records, and still feed the org's code coverage numbers. What changed is the surface and the fact that flow tests can ride along. Treat the two old page names as aliases for the current ones when you read community posts written before the rename. The function people describe is the same page you use today, just under its previous label.
Selecting which tests to run
The run starts when you click Select Tests on the page. A dialog opens with a namespace dropdown and a list of test classes. The dropdown has three modes. Picking your own namespace, shown as [My Namespace], lists only the local test classes in your org. Picking a specific managed package namespace lists the tests that shipped inside that package. Picking [All Namespaces] shows every test class the org can see, local and packaged together. This namespace control is the practical heart of the page. A subscriber who installed a managed package can run just that package's tests without wading through their own. A package developer can isolate package tests from local ones during validation. After you choose a namespace and check the classes you want, you click Run and the framework queues the work. There is no required grouping step. You are selecting test classes directly each time, so the page does not depend on you maintaining a saved list in advance. That keeps ad hoc runs quick, at the cost of repeating the selection on the next run.
Running Apex and automated flow tests together
The headline capability of the current page is mixed test types. Apex unit tests are the classic case: methods marked with the testMethod keyword or the @isTest annotation that exercise triggers and classes. Automated flow tests are newer. You build them inside Flow Builder by recording expected outcomes for a flow, and they verify that a flow still behaves as designed. Application Test Execution can run both kinds in one pass. Only flow tests created through automated flow testing in Flow Builder qualify, so a flow without saved test definitions will not appear. Running both types together gives a single readout of whether the automation in an org, code and clicks alike, still holds up. This matters because business logic in modern Salesforce orgs rarely lives in just one place. An Opportunity might be touched by an Apex trigger and a record-triggered flow. Testing only the Apex half leaves a blind spot. The page lets one run cover both, then reports failures for each with the detail you need to fix them.
Asynchronous runs and live progress
Tests launched from this page run asynchronously. The framework places them in a queue and processes them in the background, so you are not blocked while they finish. The page updates as work completes, showing how many test methods passed and how many failed. By default tests run in parallel, which finishes a large set faster but can surface conflicts if two tests fight over the same shared data. If a run is taking too long or you launched the wrong set, you can select the running tests and click Abort to cancel them. When the run finishes, results stay visible on the page for about 60 minutes. Within that window you can click any test to open its result details, including the error message and stack trace for a failure. You can also click View to open the source Apex behind a test. After that window closes, the live view clears, but the run is not lost. The record moves to Application Test History, which is where you go for older runs and durable inspection.
Code coverage and the Skip Code Coverage option
Every normal run on this page does two things at once. It records pass and fail results, and it measures code coverage, the percentage of your production Apex lines that the tests actually executed. Coverage is what gates deployment. Before you deploy to production or package for AppExchange, unit tests must cover at least 75 percent of your Apex code and all of those tests must pass. Every trigger also needs some coverage. The page gives you a Skip Code Coverage checkbox in the Select Tests dialog. Checking it runs the tests without computing coverage, which is faster and useful when you only care about whether logic passes during active debugging. Leave it unchecked when you need a true coverage reading, for example before a release. A common mistake is treating a green pass rate as deployment readiness. Pass rate and coverage are separate numbers. You can have every selected test pass while overall org coverage sits below 75 percent, and the deploy will still be blocked. Check both.
Test suites and where they actually run
A test suite is a saved collection of Apex test classes that you run as a group, handy for a repeatable pre-deployment check. It is easy to assume you create and launch suites from Application Test Execution, but the suite tooling lives in the Developer Console. There you choose Test, then New Suite, name the suite, and move classes from Available Test Classes into Selected Test Classes. To run a saved suite you choose Test, then New Suite Run. Suites are editable through Suite Manager, so you can add or drop classes as a subsystem grows without rebuilding from scratch. The Application Test Execution page, by contrast, is built around picking classes directly at run time rather than launching a named suite. So the two are complementary. Use the Setup page for quick, on-demand runs and for the namespace filtering that suites do not offer. Use Developer Console suites when you want the same defined set of classes to run the same way each time. Keep suite membership in step with your real subsystem boundaries, or a stale suite quietly stops testing the code it claims to cover.
Where this page fits among the test runners
Application Test Execution is one of several ways to run Apex tests, and it occupies a specific spot. It is the point-and-click option inside Setup for a human who wants to kick off a run and read results without leaving the browser. It shines for ad hoc checks and for the namespace-scoped runs that subscribers and package developers need. It is not the right tool for automation. Continuous integration pipelines should call the Salesforce CLI, which runs tests headlessly and returns machine-readable output that a build server can gate on. During deep debugging of a single failing test, the Developer Console often serves better because it exposes richer debug logs alongside the run. The Apex framework also offers API methods for programmatic runs when you build custom tooling. Most teams use a mix: the CLI in the pipeline, the Developer Console while writing and fixing a test, and Application Test Execution for the quick manual verification or the package-scoped check that the other tools make clumsy. Knowing which surface fits the moment saves time and avoids false confidence.
How to run tests from Application Test Execution
Use Application Test Execution to run Apex tests and automated flow tests from Setup and read the results in the browser. This is the manual, point-and-click path, best for ad hoc checks and namespace-scoped runs.
- Open the page
From Setup, type Application in the Quick Find box and select Application Test Execution. The page lists any recent run and a button to start a new one.
- Select the tests
Click Select Tests. Use the namespace dropdown to choose [My Namespace], a specific managed package namespace, or [All Namespaces], then check the test classes you want to run.
- Decide on coverage
Leave Skip Code Coverage unchecked for a true coverage reading before a release. Check it only when you want a faster pass or fail signal during debugging.
- Run and monitor
Click Run. Watch the live counts of passed and failed methods. Tests run in parallel by default; select running tests and click Abort if you need to cancel.
- Inspect results
Click any test to open its details, including the stack trace for a failure, or click View to see the source Apex. Results stay on the page for about 60 minutes.
Filters the test list to local classes, one managed package, or every visible namespace. The key control for package-scoped runs.
Runs the selected tests without computing code coverage. Faster, but it will not tell you whether you meet the 75 percent deploy gate.
Cancels selected tests while a run is in progress, useful when a parallel run stalls or you launched the wrong set.
Opens the source Apex behind a selected test result so you can read the code without leaving the page.
- A green pass rate is not the same as deploy readiness. Production deploys still require at least 75 percent overall Apex code coverage with all tests passing.
- Only flow tests built with automated flow testing in Flow Builder appear here. A flow with no saved test definitions will not show up.
- Live results clear after about 60 minutes. For older runs and durable inspection, use the Application Test History page.
- Parallel execution can cause intermittent failures when two tests share the same data. Fix the data setup rather than only disabling parallel runs.
Prefer this walkthrough as its own page? How to Application Test Execution in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Execute Application TestsSalesforce
- Application Unit TestsSalesforce
Straight from the source - Salesforce's reference material on Application Test Execution.
- Execute Application TestsSalesforce
- Manage Sets of Apex Test Classes with Test SuitesSalesforce
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 unit of selection does Application Test Execution add that plain Apex Test Execution lacks?
Q2. While an application test run is in progress, what can the page show the user?
Q3. Why is Application Test Execution useful to run before promoting changes through a Salesforce release?
Discussion
Loading discussion…