If you're cross-compiling Rust code, you may wish to run tests through a wrapper executable or script. For this purpose, nextest supports target runners, using the same configuration options used by Cargo:
- The environment variable
CARGO_TARGET_<triple>_RUNNER, if it matches the target platform, takes highest precedence.
- Otherwise, nextest reads the
If you're on Linux cross-compiling to Windows, you can choose to run tests through Wine.
If you add the following to
[target.x86_64-pc-windows-msvc] runner = "wine"
Or, in your shell:
Then, running this command will cause your tests to be run as
cargo nextest run --target x86_64-pc-windows-msvc
Note: If your target runner is a shell script, it might malfunction on macOS due to System Integrity Protection's environment sanitization. Nextest provides the
NEXTEST_DYLD_*environment variables as workarounds: see Environment variables nextest sets for more.
While cross-compiling code, some tests may need to be run on the host platform. (See the note about Filtering by build platform for more.)
For tests that run on the host platform, nextest uses the target runner defined for the host. For example, if cross-compiling from
x86_64-pc-windows-msvc, nextest will use the
CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUNNER for proc-macro and other host-only tests, and
CARGO_TARGET_X86_64_PC_WINDOWS_MSVC_RUNNER for other tests.
This behavior is similar to that of per-test overrides.
Nextest invokes target runners during both the list and run phases. During the list phase, nextest has stringent rules for the contents of standard output.
If a target runner produces debugging or any other kind of output, it MUST NOT go to standard output. You can produce output to standard error, to a file on disk, etc.
For example, this target runner will not work:
#!/bin/bash echo "This is some debugging output" $@
Instead, redirect debugging output to standard error:
#!/bin/bash echo "This is some debugging output" >&2 $@