Skip to content
This repository was archived by the owner on Nov 9, 2019. It is now read-only.

Integrate misc-tests into wasi-common#29

Merged
sunfishcode merged 9 commits intoCraneStation:masterfrom
kubkon:tests-integration
Jun 26, 2019
Merged

Integrate misc-tests into wasi-common#29
sunfishcode merged 9 commits intoCraneStation:masterfrom
kubkon:tests-integration

Conversation

@kubkon
Copy link
Copy Markdown
Member

@kubkon kubkon commented Jun 20, 2019

This PR builds on #28. It integrates tests from sunfishcode/misc-tests into wasi-common. In order to achieve more seamless integration and better control of each tested aspect, I've taken the liberty of modularising sunfishcode/misc-tests into separate testcases. The effect of this work can be seen in my fork kubkon/misc-tests.

Summary of changes:

The workspaces used (per each testcase which is essentially a separate executable Wasm module) is generated on the fly and saved in the host's temp dir. In order to avoid any race conditions, etc., each testcase module gets its own workspace dir suffixed with the timestamp of execution. This can potentially generate quite a few directories, albeit in host's temp dir, so I'm wondering whether there could be a better way of handling this. Any thoughts on this are more than welcome! :-)

EDIT: I was thinking of simply disabling all of the tests on Win, but still I'd expect the buf_random_buf testcase to pass. Somehow, this is not the case, so I'll have to investigate. Anyhow, otherwise, feel free to review the changes as I don't expect the bulk to change in the process of me fixing the Win build. OK, I've separated out tests which require preopens from those that don't, and now buf_random_buf testcase passes just fine 👍

@kubkon kubkon requested a review from sunfishcode June 20, 2019 18:18
Copy link
Copy Markdown
Member

@sunfishcode sunfishcode left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tests/runtime/wasi.rs appears to be duplicating a lot of code from wasmtime. Is there a way we could factor/organize things to minimize the duplication?

Would it be possible to instead import the wasmtime-wasi crate, and use a patch to replace its wasi-common repo with the local tree?

Another option would be to integrate misc-tests into the wasmtime repo, rather than here in the wasi-common repo. That would provide clearer layering, however it would mean that we wouldn't get many tests that could test wasi-common in isolation. However, it might not be a bad idea to start building up a testsuite for wasi-common that just works in terms of WASI API calls rather than through full wasm programs.

Thoughts?

@kubkon
Copy link
Copy Markdown
Member Author

kubkon commented Jun 25, 2019

tests/runtime/wasi.rs appears to be duplicating a lot of code from wasmtime. Is there a way we could factor/organize things to minimize the duplication?

I hate code duplication as well, so I'm all for maximising code re-use as much as possible.

Would it be possible to instead import the wasmtime-wasi crate, and use a patch to replace its wasi-common repo with the local tree?

That sounds like a great idea! I'll give it a go and see where it takes us. I actually didn't know you can do crazy things like this with Cargo, so thanks for pointing it out! :-)

Another option would be to integrate misc-tests into the wasmtime repo, rather than here in the wasi-common repo. That would provide clearer layering, however it would mean that we wouldn't get many tests that could test wasi-common in isolation. However, it might not be a bad idea to start building up a testsuite for wasi-common that just works in terms of WASI API calls rather than through full wasm programs.

Thoughts?

That's a good point. In fact, I'm currently also more inclined to have those tests as part of the wasi-common crate. It will definitely make it a lot easier to verify any future contributions if we have tests integrated directly into wasi-common and run automatically at each PR, etc. This is not to say we shouldn't have a separate testsuite in wasmtime as well.

To sum up, I'll try the patch approach first, and if that fails, I guess we can think on how to integrate misc-tests with wasmtime. Agreed? :-)

@kubkon
Copy link
Copy Markdown
Member Author

kubkon commented Jun 25, 2019

@sunfishcode OK, I've successfully managed to import wasmtime-wasi and use a patch to replace its wasi-common dependency with local copy, so we're in a much better shape now :-)

Copy link
Copy Markdown
Member

@sunfishcode sunfishcode left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice

I like your changes to misc-tests to split it into separate programs. What would you think of moving this into a CraneStation repository, named wasi-misc-tests or something?

Right now, your misc-tests repo contains the precompiled wasm files that it builds, and then you pull them in by git submodule here. I find it a little confusing, because this also pulls in the source for these tests too, however we don't actually build from the source here; we only use the precompiled versions. What would you think about checking the precompiled wasms into the wasi-common repo instead, and avoiding the submodule?

#[test]
fn sched_yield() -> Result<(), String> {
run_test_without_workspace("tests/misc-tests/bin/sched_yield.wasm")
}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would you think of auto-generating these test functions, similar to what wasm time does for the spec testsuite? That way, when we add new tests, we don't have to remember to add them here before they actually get run.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGTM! And this is exactly what I've done now so have a look :-)

Now, test binaries are bundled with the repo, and
just like in CraneStation/wasmtime, the test cases
are generated automatically using build.rs. So all
it takes is to drop a new test binary in the
testsuite dir to get the test case for it generated
(with some caveats to do with handling preopens).
@kubkon
Copy link
Copy Markdown
Member Author

kubkon commented Jun 26, 2019

Nice

I like your changes to misc-tests to split it into separate programs. What would you think of moving this into a CraneStation repository, named wasi-misc-tests or something?

Great idea! I've now cleaned up my fork of sunfishcode/misc-tests and submitted a PR upstream. After you review it and merge it, I guess we could transfer the repo to CraneStation/misc-tests and rename it to something like CraneStation/wasi-misc-tests. If you'd like I'm happy to do it, would just need admin privs to both sunfishcode/misc-tests and CraneStation ;-)

Right now, your misc-tests repo contains the precompiled wasm files that it builds, and then you pull them in by git submodule here. I find it a little confusing, because this also pulls in the source for these tests too, however we don't actually build from the source here; we only use the precompiled versions. What would you think about checking the precompiled wasms into the wasi-common repo instead, and avoiding the submodule?

Yeah, that's a fair point. My thinking here was that it would be nice to preserve some context for the test binaries we use. However, this is actually not needed since, in the end, we will still have access to the sources in a separate repo. So now, I've removed the submodule, and instead, as you suggested, bundled the test binaries directly in wasi-common in wasi-common/misc_testsuite dir. 👍

@sunfishcode
Copy link
Copy Markdown
Member

Cool. If we later decide we'd like to organize things differently, we can change things of course :-).

@sunfishcode sunfishcode merged commit 22c69f4 into CraneStation:master Jun 26, 2019
@kubkon kubkon deleted the tests-integration branch June 27, 2019 09:05
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants