-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace Karma with Web Test Runner #316
Conversation
Review or Edit in CodeSandboxOpen the branch in Web Editor • VS Code • Insiders |
TBDocs Report ✅ No errors or warnings @web5/api
TBDocs Report Updated at 2023-12-01T17:18:55Z |
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #316 +/- ##
=======================================
Coverage 91.77% 91.77%
=======================================
Files 73 73
Lines 15765 15765
Branches 1448 1448
=======================================
Hits 14469 14469
Misses 1270 1270
Partials 26 26
|
I had to shutoff playwright webkit because it's hanging. It seems to be responsible for the majority of the issues on CI, along with the macos runner. I am going to submit that we should simply use the ubuntu runner which seems less noisy and still gets us chrome and firefox with less flakes and problems. |
If anyone enjoys test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added back Webkit. Speed is pretty much identical between the two solutions except on local machines where WTR outperforms.
Biggest advantages of WTR though:
- sourcemaps working well
- not deprecated / actively maintained
- playwright actually controlling the browsers not karma
Disadvantages of WTR:
- manually bundle step rather than automated preprocessor
- watch mode will need to be manually implemented by me
.github/workflows/tests-ci.yml
Outdated
@@ -151,7 +147,7 @@ jobs: | |||
|
|||
- name: TBDocs Reporter | |||
id: tbdocs-reporter-protocol | |||
uses: TBD54566975/tbdocs@main | |||
uses: TBD54566975/tbdocs@b38d87d0c0dca088d3a82e99beea921586c67f67 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixes TBDocs failure that just popped up in the last few hours
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SDK implementers need to regularly override the dwn-server
instance used in tests which is why the TEST_DWN_URL
env var exists. It should be possible to do this for both Node and Browser tests and should not be hard coded to http://localhost:3000
.
Can you revert the removal in this PR?
Added back an env var override for DWN URL |
@@ -124,9 +124,7 @@ jobs: | |||
run: until curl -sf http://localhost:3000/health; do echo -n .; sleep .1; done | |||
|
|||
- name: Run tests for all packages | |||
run: npm run test:browser --ws -- --color | |||
env: | |||
TEST_DWN_URL: http://localhost:3000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is the same URL as default. no value here.
packages/agent/package.json
Outdated
@@ -96,7 +95,6 @@ | |||
"eslint-plugin-mocha": "10.1.0", | |||
"mocha": "10.2.0", | |||
"node-stdlib-browser": "1.2.0", | |||
"playwright": "1.40.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shamilovtim pretty sure we need to keep the @playwright/test
dev dependencies.
every time we've tried to remove them in the past and only have @playwright/test
as a dev dep, someone reports issues running tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
* poc: web test runner * add ci test * webkit is hanging * naming * shutoff webkit * unbump playwright * remove manual timeouts * use concurrency 1 * wrap up poc * run CI for poc back to back with previous impl * tie up loose ends * let wtr run to compare * add back webkit. apples to apples with karma. * remove karma * remove karma * fix tbdocs (i assume) * update ci config * better naming of scripts * fix node * revert test config changes * fix env var override * cleanup ci config * cleanup explicit deps * add back playwright
* poc: web test runner * add ci test * webkit is hanging * naming * shutoff webkit * unbump playwright * remove manual timeouts * use concurrency 1 * wrap up poc * run CI for poc back to back with previous impl * tie up loose ends * let wtr run to compare * add back webkit. apples to apples with karma. * remove karma * remove karma * fix tbdocs (i assume) * update ci config * better naming of scripts * fix node * revert test config changes * fix env var override * cleanup ci config * cleanup explicit deps * add back playwright
Reason for PR
Per #232 I spent a few hours on each different testing solution.
Jest. I found Jest to be very powerful. The amount of plugins, preprocessors, configurations, environments it runs in, etc. was impressive. However, it required significant changes to the test suite. There's a codemod for this but it's still a lot of diffs to review for maintainers.
Bare playwright. I tried to run the entire mocha test suite inside of a webpage, with browser orchestration controlled by playwright rather than Karma. This is fine it's also imperative rather than declarative. It requires me to use esbuild to bundle the tests and the browser bundle, and then shove them into a webpage with the Playwright API. I had to manually bootstrap a playwright config, setup all of the hooks, etc. There's an entire npm package that I could create to do this but I'm not sure it's worth it given that's what Web Test Runner does -- injecting a bundle in a site and controlling the orchestration with a declarative config and abstracting away the complexity.
Web Test Runner: Which brings me to this PR. It's similar to the "bare playwright" idea but it's declarative rather than imperative. Most things are managed by the
web-test-runner.config.cjs
which takes care of all of the implementation details of running something inside of playwright. The one imperative part is the fact that that I do need to bundle with esbuild first. This has implications for--watch
mode, however we could simply introduce our own --watch if needed by wrapping the bundling in a watcher. It seems there's almost no getting around jankiness like this until we migrate to the much more powerful Jest.I propose a two-phase strategy for replacing Karma:
Step 1: Employ Web Test Runner as an immediate Karma substitute, as exemplified by this PR.
Step 2: Migrate to the more powerful Jest, a more challenging but beneficial transition.
Implementation
Here I'm running Karma and WTR to compare them to each other. I kept the Karma implementation in since gutting out Karma is unnecessary to demo this POC and isolates the PR nicely while providing a comparison.