Skip to content
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

Merged
merged 30 commits into from Mar 18, 2023

Conversation

rvanasa
Copy link
Contributor

@rvanasa rvanasa commented Feb 16, 2023

Renames and adjusts unit tests for compatibility with the VS Code testing integration and mo-test CLI:

Screenshot 2023-02-15 at 5 30 35 PM

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:

  • The new test runner uses the moc.js interpreter by default (and Wasmer for files with a // @testmode wasmer annotation), while the CI continues to use wasmtime. 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).
  • A test/dfx.json file with a defaults.build.packtool config is included to patch the output of vessel 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 the package-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)!

@crusso
Copy link
Contributor

crusso commented Feb 16, 2023

I've just added RBTreeTestMore.mo to master....

@rvanasa rvanasa marked this pull request as ready for review February 17, 2023 02:37
@crusso
Copy link
Contributor

crusso commented Mar 1, 2023

curious, why wasmer instead of wasmtime? Is it more readily available via node or something?

@rvanasa rvanasa changed the title chore: refactor tests to work with VS Code integration chore: refactor tests to work with VS Code integration and mo-test command Mar 16, 2023
@rvanasa
Copy link
Contributor Author

rvanasa commented Mar 16, 2023

curious, why wasmer instead of wasmtime? Is it more readily available via node or something?

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: mo-test and the updated CI workflow both use Wasmtime in the same way as the Makefile.

@rvanasa rvanasa marked this pull request as draft March 16, 2023 18:46
@rvanasa rvanasa marked this pull request as ready for review March 16, 2023 20:22
@crusso
Copy link
Contributor

crusso commented Mar 16, 2023

Managed to run this by

npm install
npm test

which is easy enough!

Mostly works, but hangs after test RBTree (wasi) - is that expected or my VM being too slow for the interpreter?
Is there a way to run tests selectively (i.e. something like npm test RBTree?)

UPDATE: the tests finish for me if I remove the --testmode interpreter from package.json and just use wasi.

@crusso crusso closed this Mar 16, 2023
@crusso crusso reopened this Mar 16, 2023
@rvanasa
Copy link
Contributor Author

rvanasa commented Mar 17, 2023

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.

@rvanasa
Copy link
Contributor Author

rvanasa commented Mar 17, 2023

Is there a way to run tests selectively (i.e. something like npm test RBTree?)

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.

Copy link
Contributor

@crusso crusso left a 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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants