Stream: wasi

Topic: Prototype: `wasi:test`


view this post on Zulip Lann Martin (Oct 14 2025 at 19:59):

I've put together a prototype wasi:test interface and examples: https://github.com/lann/wasi-test

tl;dr:

fn this_test_always_fails(ctx: &TestContext) -> Result<(), &'static str> {
    Err("failed as expected")
}
wasi_test::suite!(this_test_always_fails);
$ wac --plug example-tests.wasm wasi-test-runner-cli.wasm -o runnable-tests.wasm
$ wasmtime run -Wcomponent-model-async runnable-tests.wasm
Test this-test-always-fails...FAIL ("failed as expected")
Contribute to lann/wasi-test development by creating an account on GitHub.

view this post on Zulip Yosh Wuyts (Oct 21 2025 at 14:30):

Oh this is neat! For the Rust HTTP sample we never got around to answering how to test it

view this post on Zulip Yosh Wuyts (Oct 21 2025 at 14:31):

Something like this seems like it might help? - though I assume that does require answering the wasi:http composition question first

view this post on Zulip Lann Martin (Oct 21 2025 at 15:26):

the wasi:http composition question

Which composition question? :slight_smile:

view this post on Zulip Yosh Wuyts (Oct 23 2025 at 19:23):

I think what I meant was: how can we test a WASI http server from WASI itself? Presumably the right way we'd want to solve that is by linking the http server into our test component, and triggering calls to the server component from there.

view this post on Zulip Yosh Wuyts (Oct 23 2025 at 19:24):

What we're doing now in e.g. wstd to test networking things is to spin up a Wasmtime instance in Rust and use that to instrument test programs externally.

view this post on Zulip Yosh Wuyts (Oct 23 2025 at 19:26):

Presumably if we had an WASI::http/server, we should be able to link that against WASI::http/middleware somehow, and us that to drive the tests?

view this post on Zulip Yosh Wuyts (Oct 23 2025 at 19:27):

But maybe I'm thinking about this wrong heh

view this post on Zulip Lann Martin (Oct 23 2025 at 19:42):

By "WASI http server" do you mean like wasmtime serve or do you mean a component exporting a wasi:http handler?

view this post on Zulip Yosh Wuyts (Oct 24 2025 at 11:57):

I meant the latter

view this post on Zulip Lann Martin (Oct 24 2025 at 12:12):

In that case wasi:test should work. The test(s) would import the handler and call into it. You'd probably want a test implementation of wasi:http to ease testing any actual application logic.

view this post on Zulip Lann Martin (Oct 24 2025 at 12:45):

Added a composition diagram to the readme

Contribute to lann/wasi-test development by creating an account on GitHub.

view this post on Zulip Yosh Wuyts (Oct 24 2025 at 13:49):

@Lann Martin the SVG isn't loading for me; maybe a broken link?

view this post on Zulip Yosh Wuyts (Oct 24 2025 at 13:49):

Clicking through does show it tho; e.g. https://github.com/lann/wasi-test/blob/main/composition.svg

Contribute to lann/wasi-test development by creating an account on GitHub.

view this post on Zulip Lann Martin (Oct 24 2025 at 13:56):

One thing to clarify there wrt your question: the "Test Runner" interfaces don't matter for the thing being tested; the CLI test runner could run tests that target an HTTP handler, for instance.

view this post on Zulip Lann Martin (Oct 24 2025 at 14:03):

Also - and maybe this is getting closer to answering your question - a more complete diagram for testing an HTTP handler would involve something providing wasi:http imports to both the "Tests Component" and the "Component Under Test". That could just be the host but for application testing you'd probably prefer an entirely separate guest implementation, both for reproducibility and to enable fancy test functionality (mocking, request/response recording, etc).


Last updated: Dec 06 2025 at 06:05 UTC