| name | run-test |
| description | Use when choosing or running JET tests after code changes. Prefer the most specific relevant test, use TestRunner for focused iteration, and reserve the full suite for broad validation. |
Run JET tests
Use this skill when validating JET changes or deciding which test command to
run.
Choose the narrowest useful test
If the user names a test file or testset, run it first. Otherwise, use
test/runtests.jl and nearby tests to identify the
smallest relevant target.
Most test files can run independently. For example:
julia --startup-file=no --project=test test/ui/test_print.jl
--startup-file=no avoids loading unrelated startup utilities.--project=test selects JET's test environment and its dependencies.- Run commands from the repository root so relative paths and the workspace
resolve correctly.
JET tests are organized by component. Common locations include:
test/abstractinterpret/test/analyzers/test/toplevel/test/ui/
There are also integration and miscellaneous tests directly under test/.
Follow test/runtests.jl rather than assuming every test has a root-level path.
Focused iteration with TestRunner.jl
When testrunner --help succeeds and the target @testset is clear, use
TestRunner.jl for faster iteration:
testrunner --project=test \
test/toplevel/test_virtualprocess.jl \
"syntax error reports"
TestRunner.jl is experimental. If it fails for a TestRunner-specific reason,
fall back to running the complete test file independently.
Full-suite validation
Avoid the full suite unless:
- Changes affect multiple components or shared compiler infrastructure.
- The user explicitly requests it.
- No narrower test provides sufficient coverage.
Use the package test lifecycle when matching CI or performing final broad
validation:
julia --startup-file=no -e 'using Pkg; Pkg.test()'
JET's workspace also supports running test/runtests.jl directly:
julia --startup-file=no --project=test test/runtests.jl
Environment failures
If a failure looks environment-related, first confirm that the command ran from
the repository root. Do not modify Project.toml or test/Project.toml to fix
the environment. Report the unresolved failure and ask the user for guidance.
Reporting
In the final response, report the exact command that ran and whether it passed,
failed, or timed out. If tests were skipped, explain why.
