Implement Summary API for tests #312
Description
The response is the current test status for a specific Project ID and Seed. This uniquely identifies the run.
It is used to find the test results for a specific test run so that we can be sure that each component has sufficient tests and that they have passed.
If we don’t know the seed, we can use the project ID and branch - then take the seed for the last run to determine the test_runs records to include.
The response should be details of the number of tests that have been run. Data returned will include a header which includes:
- Project ID
- Seed
- Branch
- SHA
- Start Time
- End Time
Status - this has to be derived from all the associated spec_runs.
Total Number of Tests - as above, derived.
Then within the response there will be information derived from the suite_runs and thence the spec_runs and their associated tags. This should be summarized grouped and summarized by
- Test Type
- Component
- Owner
We need enough information in the response to know:
How many tests were run, how many succeeded, how many failed. We need to know which components the tests were run against - think of ccs-atmos-tests, the Atmos NG Acceptance tests where tests are run against multiple components at the same time. We need to have it categorized by component. Which is a tag.
Ginkgo tests can have a status of:
- Passed: The test ran successfully and all assertions passed.
- Failed: The test ran, but at least one assertion failed, or an unexpected error occurred.
- Pending: The test was marked as pending and wasn't executed. This can be useful for outlining future test cases.
- Skipped: The test was skipped, either programmatically (e.g., using GitHub PagesSkip{/Link} in your code) or through command-line flags (like --focus or --skip).