On Tue, May 05, 2026 at 06:01:01PM +0100, Alex Bennée wrote:
> This provides basic instructions for running tests.
> 
> Signed-off-by: Alex Bennée <[email protected]>
> ---
>  .agents/skills/qemu-testing/SKILL.md | 53 ++++++++++++++++++++++++++++
>  1 file changed, 53 insertions(+)
>  create mode 100644 .agents/skills/qemu-testing/SKILL.md
> 
> diff --git a/.agents/skills/qemu-testing/SKILL.md 
> b/.agents/skills/qemu-testing/SKILL.md
> new file mode 100644
> index 00000000000..3b7b42109e1
> --- /dev/null
> +++ b/.agents/skills/qemu-testing/SKILL.md
> @@ -0,0 +1,53 @@
> +---
> +name: qemu-testing
> +description: Provides instructions on how to find, list, and run individual 
> tests for QEMU (Unit, QTest, Functional, TCG). You MUST use this skill 
> whenever the user asks about tests, wants to list available tests, or wants 
> to run any test in a build directory, even for simple exploratory queries 
> like "what tests can I run". It includes details about spawning sub-agents.
> +license: GPL-2.0-or-later
> +---
> +
> +# Instructions
> +To run QEMU tests, you can use several different suites depending on what 
> you are testing. **Note**: Ensure you have a recent build of QEMU before 
> running tests. Use the `qemu-build` skill if you need to configure or run a 
> build.
> +
> +## General Test Suites
> +- **Unit Tests**: `make check-unit`
> +- **QTest (Device emulation)**: `make check-qtest`
> +- **Functional Tests (Python based)**: `make check-functional`
> +- **TCG Tests (CPU instruction tests)**: `make check-tcg`
> +
> +## Launching Tests
> +**Crucial**: You MUST NEVER run a test suites directly in the main agent 
> context. You MUST ALWAYS launch them by spawning a sub-agent. Pass the 
> specific build or test commands, along with the required build directory, in 
> the `task` argument. Give the subagent explicit instructions on what to 
> verify and what to report back to you.
> +For example: `task: "Navigate to builds/debug and check what meson tests 
> touch replay and report back."` or `task: "Run make check-tcg in builds/arm 
> and summarize any failing tests."`
> +
> +### From the Build Directory
> +Most individual tests from within a build directory. Most (unit, qtest, 
> block, functional) can be individually selected and run via meson.
> +
> +As QEMU often needs a newer meson than the build host you should use the 
> build `pyenv` to launch it:
> +- **Example**: `./pyvenv/bin/meson test --suite thorough --list` to see what 
> tests are in the thorough test suite
> +
> +## Running Individual Tests
> +
> +### Meson Test Runner (Unit, QTest, Functional, softfloat etc)
> +To run a single test, you can use the meson test runner from within your 
> pyvenv:
> +`./pyvenv/bin/meson test [testname]`
> +Example: `./pyvenv/bin/meson test qtest-x86_64/boot-serial-test`
> +
> +### TCG Tests
> +To run individual TCG tests for a specific architecture:
> +1. Navigate to the relevant build directory, e.g.: `cd 
> tests/tcg/aarch64-softmmu`
> +2. Run a specific test with make: `make run-[testname]`
> +   Example: `make run-memory-sve`
> +3. Use `make help` within the architecture directory to see the full list of 
> available tests.
> +
> +### Functional Tests
> +Individual functional tests can be run directly using the run script 
> although from the source directory:
> +- **Example**: `./builds/all/run tests/functional/aarch64/test_virt_vbsa.py`
> +
> +### Environment Variables
> +- `V=1` for verbose output from tests.
> +- `SPEED=slow` to run slower tests that are normally skipped.

When I read this, I note there is some significant overlap with what
we write in docs/devel/testing/. 

Would it still be effective enough to merely point the agents to
docs/devel/testing and get rid of most text in this section ?

> +
> +## Reporting Results
> +**Crucial**: After completing the build and test tasks, provide a concise 
> summary of the results to the calling agent.
> +1. **Summary**: State whether the build and tests passed or failed.
> +2. **Failure Excerpts**: If any task fails, include relevant excerpts from 
> the logs (e.g., compiler errors, test failures).
> +3. **Full Paths**: Always provide the **absolute file paths** to the full 
> logs and result sets for further inspection.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|


Reply via email to