Skip to content

Commit 87acd0a

Browse files
Update results-api.mdx (#6150)
1 parent ab74b0a commit 87acd0a

File tree

1 file changed

+71
-73
lines changed

1 file changed

+71
-73
lines changed

docs/ui-coverage/results-api.mdx

Lines changed: 71 additions & 73 deletions
Original file line numberDiff line numberDiff line change
@@ -41,7 +41,7 @@ If you check this in as a dependency, your installation will fail when we update
4141

4242
## Usage
4343

44-
### **1. Fetch UI Coverage Results**
44+
### **1. Get the UI Coverage Results**
4545

4646
Write a script to fetch UI Coverage results and assert test coverage criteria. This script will be executed in CI.
4747

@@ -106,9 +106,77 @@ getUICoverageResults({
106106
})
107107
```
108108

109-
## 2. Integrate into CI workflow
109+
#### Result Details
110+
111+
The `getUICoverageResults` utility returns the following data:
112+
113+
```javascript
114+
{
115+
// The run number of the identified build.
116+
runNumber: number
117+
// The run url for the identified build.
118+
runUrl: 'https://cloud.cypress.io/projects/:project_id/runs/:run_number'
119+
// The status of the identified build.
120+
runStatus: 'passed' | 'failed' | 'errored' | 'timedOut' | 'cancelled' | 'noTests'
121+
// The url that links to UI Coverage report for the identified build.
122+
uiCoverageReportUrl: 'https://cloud.cypress.io/[...]'
123+
summary: {
124+
// Indicates whether a complete UI Coverage report was generated.
125+
// For example, if a run was cancelled and the report expected to run
126+
// for 20 specs, but only 10 ran, this would result in a partial report.
127+
isPartialReport: boolean
128+
// The report coverage from 0-100 with 2 decimal precision (e.g 92.45).
129+
coverage: number
130+
// The number of views tested and analyzed.
131+
viewCount: number
132+
// The number of interactive elements that were tested.
133+
testedElementsCount:number
134+
// The number of interactive elements that were not tested.
135+
untestedElementsCount: number
136+
}
137+
// The list of tested views and the coverage of each page.
138+
views: [{
139+
// The sanatized URL pattern shown in the report.
140+
displayName: string
141+
// The view coverage from 0-100 with 2 decimal precision (e.g 92.45).
142+
coverage: number
143+
// The number of interactive elements that were tested on this view.
144+
testedElementsCount:number
145+
// The number of interactive elements that were not tested on this view.
146+
untestedElementsCount: number
147+
// The url that links the report for this view.
148+
uiCoverageReportUrl: 'https://cloud.cypress.io/[...]'
149+
}]
150+
}
151+
```
152+
153+
### **2. Add to CI Workflow**
154+
155+
In your CI workflow that runs your Cypress tests,
156+
157+
1. Update your install job to install the `@cypress/extract-cloud-results` module.
158+
2. Pass in the necessary arguments to `getUICoverageResults`.
159+
3. Add a new step to the job that runs your Cypress tests to verify the UI Coverage results.
160+
161+
:::info
110162

111-
Add steps to your CI configuration to install the module, fetch results, and verify coverage:
163+
If you record multiple runs in a single CI build, you must record these runs using the `--tag` parameter and then call `getUICoverageResults` with the `runTags` argument for each run.
164+
165+
This is necessary to identify each unique run and return a corresponding set of results. The tags are how each run is uniquely identified.
166+
167+
**Example**
168+
169+
- Let's imagine that within a single CI build you call `cypress run --record` multiple times because you're running one set of tests against a `staging` environment, followed by a `production` environment.
170+
- In this scenario, you pass a different `--tag` to each cypress run
171+
- `cypress run --record --tag staging`
172+
- `cypress run --record --tag production`
173+
- When calling `getUICoverageResults` you would then pass these same tags to get the unique set of results for each run
174+
- `getUICoverageResults({ runTags: ['staging']})`
175+
- `getUICoverageResults({ runTags: ['production']})`
176+
177+
:::
178+
179+
#### Example Job Workflow Update:
112180

113181
<Tabs groupId="ui-cov-results-api">
114182
<TabItem value="GitHub Actions" active>
@@ -258,73 +326,3 @@ workflows:
258326

259327
</TabItem>
260328
</Tabs>
261-
262-
#### Result Details
263-
264-
The `getUICoverageResults` utility returns the following data:
265-
266-
```javascript
267-
{
268-
// The run number of the identified build.
269-
runNumber: number
270-
// The run url for the identified build.
271-
runUrl: 'https://cloud.cypress.io/projects/:project_id/runs/:run_number'
272-
// The status of the identified build.
273-
runStatus: 'passed' | 'failed' | 'errored' | 'timedOut' | 'cancelled' | 'noTests'
274-
// The url that links to UI Coverage report for the identified build.
275-
uiCoverageReportUrl: 'https://cloud.cypress.io/[...]'
276-
summary: {
277-
// Indicates whether a complete UI Coverage report was generated.
278-
// For example, if a run was cancelled and the report expected to run
279-
// for 20 specs, but only 10 ran, this would result in a partial report.
280-
isPartialReport: boolean
281-
// The report coverage from 0-100 with 2 decimal precision (e.g 92.45).
282-
coverage: float
283-
// The number of views tested and analyzed.
284-
viewCount: number
285-
// The number of interactive elements that were tested.
286-
testedElementsCount:number
287-
// The number of interactive elements that were not tested.
288-
untestedElementsCount: number
289-
}
290-
// The list of tested views and the coverage of each page.
291-
views: [{
292-
// The sanatized URL pattern shown in the report.
293-
displayName: string
294-
// The view coverage from 0-100 with 2 decimal precision (e.g 92.45).
295-
coverage: float
296-
// The number of interactive elements that were tested on this view.
297-
testedElementsCount:number
298-
// The number of interactive elements that were not tested on this view.
299-
untestedElementsCount: number
300-
// The url that links the report for this view.
301-
uiCoverageReportUrl: 'https://cloud.cypress.io/[...]'
302-
}]
303-
}
304-
```
305-
306-
### **2. Add to CI Workflow**
307-
308-
In your CI workflow that runs your Cypress tests,
309-
310-
1. Update your install job to install the `@cypress/extract-cloud-results` module.
311-
2. Pass in the necessary arguments to `getUICoverageResults`.
312-
3. Add a new step to the job that runs your Cypress tests to verify the UI Coverage results.
313-
314-
:::info
315-
316-
If you record multiple runs in a single CI build, you must record these runs using the `--tag` parameter and then call `getUICoverageResults` with the `runTags` argument for each run.
317-
318-
This is necessary to identify each unique run and return a corresponding set of results. The tags are how each run is uniquely identified.
319-
320-
**Example**
321-
322-
- Let's imagine that within a single CI build you call `cypress run --record` multiple times because you're running one set of tests against a `staging` environment, followed by a `production` environment.
323-
- In this scenario, you pass a different `--tag` to each cypress run
324-
- `cypress run --record --tag staging`
325-
- `cypress run --record --tag production`
326-
- When calling `getUICoverageResults` you would then pass these same tags to get the unique set of results for each run
327-
- `getUICoverageResults({ runTags: ['staging']})`
328-
- `getUICoverageResults({ runTags: ['production']})`
329-
330-
:::

0 commit comments

Comments
 (0)