Application Test History
Application Test History is the Salesforce Setup page that shows the results of recent application-level Apex test runs.
Definition
Application Test History is the Salesforce Setup page that shows the results of recent application-level Apex test runs. It lives at Setup, Custom Code, Application Test History and is the natural companion to Application Test Execution: where Application Test Execution launches a suite, Application Test History retains the outcomes. Each row on the page represents one run, with the suite name, the submitting user, the start time, the elapsed time, the pass and fail counts, and a drill-down link into the individual ApexTestResult records. The page exists so admins and developers can compare runs over time, spot regressions, and inspect older failures without re-running the suite.
Salesforce retains test run data for a rolling window measured in weeks rather than months. The retention policy reflects the platform's storage constraints; long-term trend analysis requires exporting ApexTestResult rows to a custom history object on a schedule. For most ad hoc inspection (last week's release validation, yesterday's regression spike), the built-in history is enough. For compliance retrospectives or quarterly quality reviews, a parallel snapshot pipeline is the standard pattern. The Apex Test History page (a parallel surface at Setup, Custom Code, Apex Test History) shows the same data filtered to class-level rather than suite-level runs.
How Application Test History supports test trend analysis
What each row in the page represents
Each row is one ApexTestRunResult record: a single launch of a Test Suite or selected classes. Fields include the Run ID, submitting user, start time, end time, total methods, methods passed, methods failed, methods skipped, and overall status. Clicking the row opens a detail view with per-class breakdown and links to every failed ApexTestResult.
Filtering and date range
The default view shows recent runs in reverse chronological order. Filters narrow by user, suite, status (Completed, Failed, Aborted), and date range. Most teams build a saved view scoped to release-validation runs so they can confirm release readiness at a glance.
Drilling into a failed run
Clicking a failed run opens the detail page with every failed method, the assertion message, and the stack trace. Cross-references to Apex Jobs and the underlying classes are inline. Failed runs are the page's primary use case; passed runs are mostly background noise.
ApexTestRunResult and ApexTestResult
Both objects are queryable through SOQL. Custom dashboards can sit on top of them to surface failure trends, average elapsed time, and coverage per suite. Production teams who want long-term trend data export these rows to a custom history object weekly.
Retention and the snapshot pattern
Salesforce retains test run data for a rolling window. Beyond that window, the page returns empty results. The snapshot pattern (a scheduled Apex job that copies ApexTestRunResult and ApexTestResult into a custom Test_History__c object) preserves the data indefinitely for compliance and trend analysis.
Comparing across versions
Test History is most useful when comparing two consecutive runs of the same suite. Did the latest run regress any previously-passing methods? Did elapsed time grow? Did coverage drop? Those three questions answer most release-readiness debates and are easy to surface from the historical data.
Integration with CI/CD
Pipelines that submit Apex test runs through the CLI also produce ApexTestRunResult records. Application Test History shows those CLI-driven runs alongside Setup-launched runs. Operations teams sometimes treat the page as a unified dashboard for both human-initiated and automated test runs.
Common gotchas
Three patterns recur. Retention is short, so missing data is normal beyond a few weeks. Aggregate pass counts mask individual flaky tests; the per-method view is the only reliable signal. And the page does not surface code coverage; that lives on the Code Coverage page and must be checked separately.
How to use Application Test History effectively
The page is a thin UI over standard test-run records. Most of the value comes from reading it consistently as part of a release cadence, not from one-off visits.
- Open Application Test History
Setup, Custom Code, Application Test History. Default view shows recent runs in reverse chronological order.
- Filter to relevant runs
Apply filters by user, suite, status, and date range. Save a view for release-validation runs so the team can return to it quickly.
- Compare consecutive runs
Pick the two most recent runs of the target suite. Compare pass rate, elapsed time, and failure list. Regressions usually appear as one or two new failed methods that succeeded the last run.
- Drill into failures
Click failed runs. Read the stack trace and assertion message. Cross-reference with Apex Jobs if the failure involves async paths.
- Export for trend analysis
Schedule a batch job that copies ApexTestRunResult and ApexTestResult rows to a custom history object weekly. Build a Lightning dashboard on top for quarterly retrospectives.
- Retention is weeks, not months. Plan a snapshot pipeline for any trend analysis beyond a few weeks.
- Aggregate pass counts can hide flaky tests. Per-method history is the only reliable signal for intermittent failures.
- Code coverage is not on the page. Check the Code Coverage page separately before any production deploy.
- Cancelled runs appear in history with partial data. They are useful only for run-start metadata, not for outcome analysis.
Trust & references
Cross-checked against the following references.
- Apex Test Execution and HistorySalesforce Help
- Running Apex TestsApex Developer Guide
Straight from the source - Salesforce's reference material on Application Test History.
- ApexTestRunResult API ReferenceSalesforce Developer Docs
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. Where would a developer typically work with Application Test History?
Q2. What is required before deploying Application Test History-related code to production?
Q3. What skill set is typically needed to work with Application Test History?
Discussion
Loading discussion…