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
chore: refactor tests to work with VS Code integration and mo-test
command
#527
Conversation
…ryan/unit-test-vscode
…ryan/unit-test-vscode
I've just added RBTreeTestMore.mo to master.... |
curious, why wasmer instead of wasmtime? Is it more readily available via node or something? |
…ryan/unit-test-vscode
…toko-base into ryan/unit-test-vscode
mo-test
command
Just saw this; that's correct. Wasmer is distributed as an npm package, so it's trivial to bundle a platform-independent installation with the extension. This is mostly just a placeholder for dfinity/node-motoko#66, which will use the built-in Node.js Wasm runtime. Update: |
Managed to run this by
which is easy enough! Mostly works, but hangs after test RBTree (wasi) - is that expected or my VM being too slow for the interpreter? UPDATE: the tests finish for me if I remove the |
Good to know, and thanks for trying this out locally. I removed the interpreter tests for now and will set up the multiple runtime testing in a subsequent PR. |
This is next on the list of features to implement. I'm still deciding how this will work (e.g. exact name vs. partial/wildcard/regex matching), so let me know if you have an opinion on this. |
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.
Thanks for updating the README. As long as the old makefile stuff doesn't break, I'm more than happy for you to merge and keep iterating. Good stuff!
Renames and adjusts unit tests for compatibility with the VS Code testing integration and
mo-test
CLI:The CI now uses
mo-test
and JS helper scripts in place of the Makefile, which drastically simplifies the setup process for running tests on a local machine.This PR also begins a convention of designating unit tests with the
.test.mo
extension, which gives test runners a way to automatically register test files from any project layout (similar to JavaScript's.test.js
and.spec.js
file extensions).A few notes:
// @testmode wasmer
annotation), while the CI continues to usewasmtime
. The eventual goal is to distribute this new test runner as a CLI supporting all of these runtimes (with the ability to exclude tests from certain runtimes using@testmode
comments).test/dfx.json
file with adefaults.build.packtool
config is included to patch the output ofvessel sources
to use the local base library. This enables third-party contributors to use the test runner without any additional setup. The ideal solution would be to define a local package in thepackage-set.dhall
file, but this would require everyone to reinstall Vessel and introduce a breaking change prior to the upcoming redesign. As a result, this seems like a more community-friendly solution for the time being.Feedback welcome (as always)!