-
-
Notifications
You must be signed in to change notification settings - Fork 45
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
Implement carton test
command
#42
Comments
In the latest 5.3 toolchain all known issues with IndexStoreDB and SwiftPM support were resolved. Resolves the second point of #42. Thanks to this you no longer need to maintain `LinuxMain.swift` and `XCTestManifests.swift` files in your test suites, so these are deleted from the test app `Tests` directory.
Resolves #42. Also updates JavaScriptKit dependency to 0.9.0. * Demangle and print Firefox stacktraces in terminal * Update the entrypoints archive URL, rename file * Add missing newline to `ProcessRunner.swift` * Remove redundant `console.log` call from `dev.js` * Detect destination env from `User-Agent` header * Silence linter in tests where it can't be avoided * Add support for basic testing in browsers * Add a browser message on finish, shut down server * Update JavaScriptKit to 0.9.0
@MaxDesiatov a couple of questions on this. When we test. We're running a JS Script that tests against the wasm file. Is there any way to mimic UITests and reference "IDs" or names generated in the HTML? If there is a way for introspection and use by the test harness, then we shouldn't care about a browser. We could use pure swift, and test browsers as a secondary effort. |
Unfortunately, I don't think that's possible without parsing that HTML and maybe even having a complete DOM environment with WebAssembly support. I reckon that in some way it would be an effort comparable to maintaining our own small browser engine. I may be wrong and I'm happy to consider any viable options though. |
This should build tests, passing the resulting binary to a test runner after that. This could be implemented in a few separate steps:
wasmer
as a basic CLI test runner;--enable-test-discovery
flag to inject the JSON test observer so that test reports can be parsed (blocked by the lack oflibIndexStore.dylib
in recent snapshots);consider using Node.js as another CLI runner option?Tracked separately in Node.js support as a destination environment #174makeTracked separately in Make Wasmer an optional dependency? #177wasmer
an optional dependency.There's a question of how the target environment is selected. The
wasmer
option is what will be implemented first, and probably will be the default, but when browser environments are supported, shouldcarton test
launch tests in parallel in all possible environments? What should the appropriate option name be for selecting a specific test runner?--target
(as in "the target environment"),--host
(as in "the webassembly host"),--environment
(probably the most unambiguous),--runner
? I'm currently thinking of--environment
, but all feedback is welcome as usual.The text was updated successfully, but these errors were encountered: