Application Test History
Application Test History is the Salesforce Setup page that lists the results of Apex test runs that executed asynchronously in your org.
Definition
Application Test History is the Salesforce Setup page that lists the results of Apex test runs that executed asynchronously in your org. You reach it from Setup by entering Application in the Quick Find box and selecting Application Test History. It is also called the Apex Test History page, and it is available in Lightning Experience only.
The page is the record of what happened after a run. Application Test Execution launches a set of tests, and Application Test History keeps the outcomes so you can review them later. The page shows test runs by ID. Click a run to see every test method it covered, then filter to passed methods, failed methods, or all of them. Salesforce keeps these results for 30 days after a run finishes, unless someone clears them sooner.
How the history page fits the Apex testing flow
Where it sits in Setup and who can see it
The page lives under Setup. Type Application in the Quick Find box and pick Application Test History from the results. You can also get there from a sibling page: open Application Test Execution and click the View Test History link. Both routes land on the same historical view. The feature is available in Lightning Experience, in the Enterprise, Performance, Unlimited, Developer, and Database.com editions. It does not appear in Salesforce Classic, so a team still on Classic for daily admin work has to switch to Lightning to read it. One detail that surprises new admins is scope. The history shows results for the whole org, not just the runs you personally started. A run kicked off by a teammate, by a scheduled job, or by a deployment all appear in the same list. That makes the page a shared record of test activity rather than a private log. It also means the list can grow busy in an active org, which is why the per-run filters and saved views matter for reading it quickly.
What a row and a drill-down actually show
The top level of the page lists test runs by their run ID. Each row carries a Status indicator that reports the number of failed and enqueued methods for that run. Enqueued means a method is still waiting in the asynchronous test queue, so a run that is mid-flight shows up before it finishes. Click a run ID and the page expands to the test methods that ran inside it. From there you choose what to display: only the methods that passed, only the ones that failed, or every method in the run. Click a test class name to open the detail view for that result. The detail view is where the useful failure information lives. It shows which method failed, the assertion or error message it produced, and the stack trace that points back into the code. Passing methods rarely need attention, so most of the time you go straight to the failed set. The drill-down is the difference between knowing a run failed and knowing why it failed.
The 30-day retention window
Salesforce retains these test results for 30 days after a run finishes, unless they are cleared first. After 30 days the run drops off the page and the data is gone from this surface. That window is fine for the everyday job the page does: checking last week's release validation, looking at yesterday's failures, confirming a flaky test settled down. It is not enough for anything that needs a long memory. Quarterly quality reviews, audit trails, and year-over-year trend charts all outlive 30 days. Teams that need that history build a snapshot pipeline. A scheduled Apex job queries the underlying ApexTestRunResult and ApexTestResult records and copies the rows into a custom object that you control. The custom object keeps the data for as long as your retention rules allow. Treat the Setup page as the live, short-term view and the custom object as the archive. Knowing the limit matters most when data goes missing: an empty page for an old run is the retention window doing its job, not a bug.
The objects behind the page
The page is a friendly view over two API objects. ApexTestRunResult holds the summary for a whole run. It represents all the test methods that ran in one Apex job and is available in API version 37.0 and later. ApexTestResult holds the outcome of a single test method, including its pass or fail status, and is available in API version 23.0 and later. One ApexTestRunResult ties to many ApexTestResult rows, which is exactly the run-to-method shape you see on screen. Because both objects are queryable, you are not limited to the Setup UI. You can write SOQL against them in the Developer Console, pull them through the Tooling API, or surface them in a report or dashboard. That opens up views the page itself does not give you, such as failure rate per class over time or average run duration. The Setup page is the quick read; the objects are the raw material when you want to build something more durable on top.
Reading runs from automation and the CLI
Not every run on this page comes from a person clicking a button. Asynchronous test runs started by the Salesforce CLI, by a deployment that runs tests, or by a scheduled job all produce the same ApexTestRunResult records. So they all show up in Application Test History next to the runs an admin launched by hand. This makes the page a single place to confirm that an automated run actually happened and what it returned. After a pipeline deploys to a sandbox and runs its tests, you can open the history and see the run, its status, and the failed methods if any. It is a useful sanity check when a build tool reports a result you want to confirm inside the org. The page will not replace a proper CI dashboard, and it does not show build logs or pipeline steps. But for the narrow question of did the tests run and did they pass, it answers directly from the platform's own record rather than a third-party tool.
Comparing two runs to catch regressions
A single run tells you a snapshot: this many passed, this many failed, right now. It cannot tell you whether anything got worse. For that you compare two runs of the same scope, usually the run before a change and the run after it. Three questions cover most release-readiness debates. Did any method that passed last time fail this time? That is a regression and the most important signal. Did the failure count go up? Did a method that was enqueued or failing finally clear? Working through the failed set of the newer run against the older one is the manual version of a regression check. Because the data also lives in ApexTestRunResult and ApexTestResult, you can automate the same comparison with a report or a small script once 30 days of in-page history is not enough. One caution: the page tracks pass and fail, not code coverage. Coverage is a separate concern with its own surface, so a green history does not by itself prove you cleared the deployment coverage requirement.
Trust & references
Cross-checked against the following references.
- View Application Test HistorySalesforce
- View Application Test ResultsSalesforce
Straight from the source - Salesforce's reference material on Application Test History.
- View Application Test HistorySalesforce
- ApexTestRunResult | Object ReferenceSalesforce
Hands-on resources to go deeper on Application Test History.
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. Each row on the Application Test History page corresponds to what?
Q2. Because Salesforce retains test-run data only for a rolling window of weeks, what pattern do teams use to keep results long term?
Q3. When comparing two consecutive runs of the same suite in Application Test History, which question is the page best suited to answer?
Discussion
Loading discussion…