chore: rewrite tests#1081
Conversation
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 11c6b16:
|
Codecov Report
@@ Coverage Diff @@
## main #1081 +/- ##
===========================================
- Coverage 100.00% 99.46% -0.54%
===========================================
Files 88 92 +4
Lines 2061 2070 +9
Branches 691 694 +3
===========================================
- Hits 2061 2059 -2
- Misses 0 11 +11
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
timdeschryver
left a comment
There was a problem hiding this comment.
I didn't review all files, but I like the idea behind this PR.
But, I reviewed the CI output, and here I saw two things that need some investigation:
- the build step warns for a circular dependency
- the test step has failed tests, but the step is green
|
Thanks for the review.
Because they end up in the same IIFE, this isn't a problem here.
Yes, I thought about this for a while. |
|
🎉 This PR is included in version 14.5.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
| @@ -0,0 +1,5 @@ | |||
| /* eslint-disable @typescript-eslint/no-unnecessary-condition */ | |||
|
|
|||
| import def, * as named from '@testing-library/dom' | |||
There was a problem hiding this comment.
This seems to cause some problems since there is no default export from @testing-library/dom. I haven't seen this kind of approach before, just curious, what is the reason for writing it this way?
What:
Edit tests to work outside of Jest.
Add script and CI to run tests in multiple environments.
Why:
This allows us to discover conflicts with environments.
#1019
How:
Eliminate dependencies on Jest specific features.
Use
@ph.fritsche/toolboxto build, serve and test the project code in Chrome and Node+Jsdom.Issue with code coverage:
Without additional work this results in Jest only running one set of dependencies. Therefore the resulting coverage lacks the cases specific to React17.
The coverage threshold has to be removed. We have
codecov/codecov-actionthat still warns us about drops in code coverage.The coverage produced by
@ph.fritsche/toolbox(per@swc/coreandistanbul-lib-instrument) differs from the coverage produced bykcd-scripts test(per@babeland ?).It seems that it reports stricter coverage e.g. on nullish coalescing. I'm not sure if it's safe to just merge these with the coverage from
kcd-scripts.In the end the coverage threshold doesn't tell us if the tests are sufficient. Running the tests in other environments provides more value than the coverage threshold, I'd merge this so that we can address the pending PRs as we now have the feedback if they introduce more/new problems in real browsers.
Checklist: