1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
|
# test-programs
This crate contains many different binaries which are built into Wasm test
programs for other crates in the Wasmtime workspace.
Each file in `./src/bin/` is built into a distinct test binary. By convention,
the prefix before the first underscore in each binary is the name of the test
suite: `api`, `cli`, `http`, `nn`, `piped`, `preview1`, and `preview2`.
## Test suites
### api
This suite is used for exercising `wasmtime`'s Rust APIs. Each test program in
this suite has particular behavior which interacts with the tests themselves.
These test programs are executed in `/crates/wasi/tests/api.rs`.
### cli
This suite is used for exercising the `wasmtime-cli` crate, which produces the
`wasmtime` native executable. Each test program in this suite has particular
behavior which interacts with the commands and arguments passed to the
wasmtime CLI. Some use the `wasmtime run` command and others the `wasmtime
serve` command.
These test programs are executed in `/tests/all/cli_tests.rs`.
### http
This test suite is used for exercising the `wasmtime-wasi-http` crate. Each
test program in this suite is a component which exports the wasi-cli command
world's run interface (i.e. its entrypoint is defined by `fn main() {...}`),
and is given the cli command world imports as well as the wasi-http
outgoing-handler and types imports - in short, this is a basic executable
which can make http requests using wasi-http.
Each test program executor spawns a fresh tokio runtime on a unique local
socket which responds to the requests made by a single test program. This
socket address is passed to the test program using the `HTTP_SERVER`
environment variable.
These test programs are executed in `/crates/wasi-http/tests/all/sync.rs`
and `/crates/wasi-http/tests/all/async_.rs`, which test the synchronous and
async rust interfaces of the `wasmtime` and `wasmtime-wasi-http` crates,
respectively.
### nn
This test suite is used for exercising the `wasmtime-wasi-nn` crate. It only
tests the witx ABI of the wasi-nn proposal.
These test programs are executed in `crates/wasi-nn/tests/all.rs`.
### piped
This suite is used for exercising the wasmtime-cli and, in particular,
examining the behavior when the standard output of one instance is piped to
the input of another instance. The test programs in this suite are passed
the environment variable `PIPED_SIDE` with the value `PRODUCER` or `CONSUMER`
to select the behavior of producing output to stdout, or consuming input
on stdin.
These test programs are executed in `/tests/all/cli_tests.rs`, which creates
two separate `wasmtime` host processes, with the consumer process stdin file
descriptor set to the producer process stdout file descriptor. The test
harness asserts that both processes exit successfully.
### preview1
This suite is used for exercising the Wasi Preview 1 (aka Wasi 0.1) interface,
and, additionally, provides test coverage of Wasi Preview 2 (aka Wasi 0.2)
when used with the component adapter, as described below.
Some of these tests require the stdin stream provided is always empty and
closed, others require that the stdin stream is open and pending forever. The
test execution provides this by inheriting the host process stdio in some test
program invocations, and providing the default null stdio in others.
All of these tests require an empty directory be provided as a preopen, and
the path of that preopen passed as the first argument.
The Wasmtime tree has three distinct ways to implement the Wasi 0.1 interface,
which should all provide identical functionality:
* The Wasm Module is executed against the host implementation of Wasi 0.1
provided by the `wasi-common` crate. The test programs are executed
in `/crates/wasi-common/tests/all/{sync,async_}.rs` against the synchronous
and async Rust interfaces of the `wasmtime` and `wasi-common` crate.
* The Wasm Module is executed against the host implementation of Wasi 0.1
provided by the `wasmtime-wasi` crate. This Wasi 0.1 interface is implemented
using the Wasi 0.2 implementation defined in that same crate. The test
programs are executed in `/crates/wasi/tests/all/preview1.rs` against the
synchronous Rust interfaces of the `wasmtime` and `wasmtime-wasi` crates.
* The Wasm Component created by composing the Module with the
`wasi-preview1-component-adapter`, which provides a pure WebAssembly
implementation of the Wasi 0.1 import functions in terms of the Wasi 0.2
import functions. When run in the host implementation of Wasi 0.2 provided
by the `wasmtime-wasi` crate, this mode of execution exercises the Wasi 0.2
interfaces, and ensures that a faithful implementation of Wasi 0.1 can be
provided in terms of them, without needing any support for Wasi 0.1 in the
host. The test programs are executed in
`crates/wasi/tests/all/{sync,async_}.rs` against the synchronous and async
Rust interfaces of the `wasmtime` and `wasmtime-wasi` crates.
### preview2
This suite is used for exercising the portions of Wasi Preview 2 (aka Wasi
0.2) which are not covered by the Wasi 0.1 + component adapter, as described
in the preview1 suite above.
These test programs use `wit-bindgen` to generate bindings to Wasi 0.2
(invoked at the root of the `test-programs` crate), and then invoke those
bindings directly in each test. The modules created from these test programs
still have imports of Wasi 0.1 thanks to the Rust `std` library, so those
imports are implemented by the same `wasi-preview1-component-adapter` as in
the preview1 suite. (When Rust stabilizes the `wasm32-wasip2` target, this
will finally get to be removed!) However, the tests themselves should be
exercising the Wasi 0.2 interfaces directly - in some cases, such as the
socket tests, its exercising functionality that Wasi 0.1 lacked.
These tests are executed much like the component adapted preview1 test suite
is, in `crates/wasi/tests/all/{sync,async_}.rs`.
## Building and executing these test programs
These tests are built and consumed by way of the `test-programs-artifacts`
crate. `test-programs-artifacts` has a `build.rs` which compiles this crate
and translates some of the resulting Wasm Modules to Wasm Components. It then
exposes the filesystem paths of these binaries as string constants, and as
macros which iterate over the complete set of binary paths in a given test
suite.
The filesystem path to each Wasm Module built by `test-programs-artifacts`
is provided by a `pub const <TESTNAME>: &'static str = ...;` at the top
level of that crate, where `<TESTNAME>` is the file stem of the source file
in `./src/bin`, in shouty snake case (all caps and underscores).
The filesystem path to each Wasm Component built by `test-programs-artifacts`
is provided by a `pub const <TESTNAME>_COMPONENT: &'static str = ...;` at the top
level of that crate, where `<TESTNAME>` is the file stem of the source file
in `./src/bin`, in shouty snake case (all caps and underscores), and then the
suffix `_COMPONENT` is added to the identifier to distinguish it from the
module.
Wasm Components are not built for the `nn` test suite. All other components
are created, using the `wasi-preview1-component-adapter` to translate Wasi 0.1
module imports to Wasi 0.2 component imports.
Each test suite is given an iterator macro in `test-programs-artifacts` named
`foreach_<suitename>`.
The iterator macro is passed the identifier of another macro which is passed
the path of each test in the suite. You could do something very clever with
this if you desire, but as of this writing, all use sites in the workspace
pass it a macro `assert_test_exists` which emits a `use <testname> as _;`
statement. This ensures that, in the rust mod where `foreach_<suitename>` is
invoked, a `fn <testname>() {...}` is defined, which in turn makes sure that,
if a wasmtime developer adds a new test program, they also add a test which
executes it in the appropriate location.
By convention, the expectation is that each mod that invokes
`foreach_<suitename>!(assert_test_exists);` also defines something like:
```
#[test]
fn <testname>() {
// do something which executes <TESTNAME> or
// <TESTNAME>_COMPONENT here.
}
```
|
