You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: README.md
+2
Original file line number
Diff line number
Diff line change
@@ -127,6 +127,8 @@ Each test suite generates a report in CircleCI. For a complete overview of testi
127
127
128
128
Our code coverage is generated during the runtime of our unit, e2e, and visual tests. The combination of those reports is published to [codecov.io](https://app.codecov.io/gh/nasa/openmct/)
129
129
130
+
For more on the specifics of our code coverage setup, [see](TESTING.md#code-coverage)
131
+
130
132
# Glossary
131
133
132
134
Certain terms are used throughout Open MCT with consistent meanings
Copy file name to clipboardexpand all lines: TESTING.md
+77-6
Original file line number
Diff line number
Diff line change
@@ -37,14 +37,85 @@ Documentation located [here](./e2e/README.md)
37
37
38
38
## Code Coverage
39
39
40
-
* 100% statement coverage is achievable and desirable.
40
+
It's up to the individual developer as to whether they want to add line coverage in the form of a unit test or e2e test.
41
41
42
-
Codecov.io will combine each of the above commands with [Codecov.io Flags](https://docs.codecov.com/docs/flags). Effectively, this allows us to combine multiple reports which are run at various stages of our CI Pipeline or run as part of a parallel process.
42
+
Line Code Coverage is generated by our unit tests and e2e tests, then combined by ([Codecov.io Flags](https://docs.codecov.com/docs/flags)), and finally reported in GitHub PRs by Codecov.io's PR Bot. This workflow gives a comprehensive (if flawed) view of line coverage.
43
+
44
+
### Karma-istanbul
45
+
46
+
Line coverage is generated by our `karma-coverage-istanbul-reporter` package as defined in our `karma.conf.js` file:
47
+
48
+
```js
49
+
coverageIstanbulReporter: {
50
+
fixWebpackSourcePaths:true,
51
+
skipFilesWithNoCoverage:true,
52
+
dir:'coverage/unit', //Sets coverage file to be consumed by codecov.io
53
+
reports: ['lcovonly']
54
+
},
55
+
```
56
+
57
+
Once the file is generated, it can be published to codecov with
The e2e line coverage is a bit more complex than the karma implementation. This is the general sequence of events:
65
+
66
+
1. Each e2e suite will start webpack with the ```npm run start:coverage``` command with config `webpack.coverage.js` and the `babel-plugin-istanbul` plugin to generate code coverage during e2e test execution using our custom [baseFixture](./baseFixtures.js).
67
+
1. During testcase execution, each e2e shard will generate its piece of the larger coverage suite. **This coverage file is not merged**. The raw coverage file is stored in a `.nyc_report` directory.
68
+
1.[nyc](https://github.com/istanbuljs/nyc) converts this directory into a `lcov` file with the following command `npm run cov:e2e:report`
69
+
1. Most of the tests are run in the '@stable' configuration and focus on chrome/ubuntu at a single resolution. This coverage is published to codecov with `npm run cov:e2e:stable:publish`.
70
+
1. The rest of our coverage only appears when run against `@unstable` tests, persistent datastore (couchdb), non-ubuntu machines, and non-chrome browsers with the `npm run cov:e2e:full:publish` flag. Since this happens about once a day, we have leveraged codecov.io's carryforward flag to report on lines covered outside of each commit on an individual PR.
43
71
44
-
This e2e coverage is combined with our unit test report to give a comprehensive (if flawed) view of line coverage.
45
72
46
73
### Limitations in our code coverage reporting
74
+
Our code coverage implementation has some known limitations:
The following is an evolving guide to troubleshoot CI and PR issues.
81
+
82
+
### Github Checks failing
83
+
There are a few reasons that your GitHub PR could be failing beyond simple failed tests.
84
+
* Required Checks. We're leveraging required checks in GitHub so that we can quickly and precisely control what becomes and informational failure vs a hard requirement. The only way to determine the difference between a required vs information check is check for the `(Required)` emblem next to the step details in GitHub Checks.
85
+
* Not all required checks are run per commit. You may need to manually trigger addition GitHub checks with a `pr:<label>` label added to your PR.
86
+
87
+
### Flaky tests
88
+
There are two ways to know if a test on your branch is historically flaky:
89
+
1.`deploysentinel`'s PR comment bot to give an accurate and historical view of e2e flakiness. Check your PR for a view of the test failures and flakes (with link to the failing test). Note: only a 7 day window of flake is available.
90
+
2. (CircleCI's test insights feature)[https://circleci.com/blog/introducing-test-insights-with-flaky-test-detection/] collects historical data about the individual test results for both unit and e2e tests. Note: only a 14 day window of flake is available.
91
+
92
+
### Local=Pass and CI=Fail
93
+
Although rare, it is possible that your test can pass locally but fail in CI.
94
+
95
+
#### Busting Cache
96
+
In certain circumstances, the CircleCI cache can become stale. In order to bust the cache, we've implemented a runtime boolean parameter in Circle CI creatively name BUST_CACHE. To execute:
97
+
1. Navigate to the branch in Circle CI believed to have stale cache.
98
+
1. Click on the 'Trigger Pipeline' button.
99
+
1. Add Parameter -> Parameter Type = boolean , Name = BUST_CACHE ,Value = true
100
+
1. Click 'Trigger Pipeline'
101
+
102
+
#### Run tests in the same container as CI
103
+
104
+
In extreme cases, tests can fail due to the constraints of running within a container. To execute tests in exactly the same way as run in CircleCI.
105
+
106
+
```sh
107
+
// Replace {X.X.X} with the current Playwright version
108
+
// from our package.json or circleCI configuration file
Copy file name to clipboardexpand all lines: e2e/README.md
+4-12
Original file line number
Diff line number
Diff line change
@@ -490,15 +490,7 @@ Our e2e code coverage is captured and combined with our unit test coverage. For
490
490
491
491
#### Generating e2e code coverage
492
492
493
-
Code coverage is collected during test execution using our custom [baseFixture](./baseFixtures.js). The raw coverage files are stored in a `.nyc_report` directory to be converted into a lcov file with the following [nyc](https://github.com/istanbuljs/nyc) command:
494
-
495
-
```npm run cov:e2e:report```
496
-
497
-
At this point, the nyc linecov report can be published to [codecov.io](https://about.codecov.io/) with the following command:
498
-
499
-
```npm run cov:e2e:stable:publish``` for the stable suite running in ubuntu.
500
-
or
501
-
```npm run cov:e2e:full:publish``` for the full suite running against all available platforms.
493
+
Please read more about our code coverage [here](../TESTING.md#code-coverage)
502
494
503
495
## Other
504
496
@@ -548,10 +540,10 @@ A single e2e test in Open MCT is extended to run:
548
540
- How is Open MCT extending default Playwright functionality?
549
541
- What about Component Testing?
550
542
551
-
### Troubleshooting
543
+
### e2e Troubleshooting
544
+
545
+
Please follow the general guide troubleshooting in [the general troubleshooting doc](../TESTING.md#troubleshooting-ci)
552
546
553
-
- Why is my test failing on CI and not locally?
554
-
- How can I view the failing tests on CI?
555
547
- Tests won't start because 'Error: <http://localhost:8080/># is already used...'
556
548
This error will appear when running the tests locally. Sometimes, the webserver is left in an orphaned state and needs to be cleaned up. To clear up the orphaned webserver, execute the following from your Terminal:
0 commit comments