riot test

riot test is the workspace entrypoint for test execution.

The default form runs every discovered test suite:

riot test

That is the command you should be able to rely on in every Riot workspace.

Narrowing what runs

riot test accepts both package-level filtering and query-style narrowing.

Run only one package:

riot test -p std

Pass a query string:

riot test archive

The command help also calls out the package:suite shape when you want to target one suite more precisely.

This matters because once a workspace has more than a handful of test binaries, “run everything” stops being the only useful loop.

JSON output

If the tests need to feed automation, use JSON mode:

riot test --json

That emits JSONL events instead of human summaries. This is the mode you want for:

• CI integrations
• editor integrations
• local tooling that should react to events instead of scraping terminal text

Verbose mode

When a suite captures useful stdout or stderr, increase verbosity:

riot test -v
riot test -vv

Verbose mode is useful when a failure is obvious in the suite output but not in the condensed default summary.

How the output is structured

In human mode, Riot prints:

• a suite header
• each test result
• a per-suite summary
• a final workspace summary

Property tests are identified separately from plain unit tests, and successful property tests report their example count instead of only ok.

What counts as “one suite”

Riot does not think in terms of loose test files. It thinks in terms of test binaries. Each binary is one suite with:

• a package name
• a suite name
• a list of exported test cases

That model is why test execution stays coherent across the workspace instead of devolving into ad hoc file discovery.

The practical loop

In day-to-day work:

1. use riot check while editing
2. use riot test when behavior matters
3. use riot test -p <pkg> when the workspace is large
4. use riot test --json when the caller is another program