e2e-test-core-tool

End-to-end test async Rust core tools against live infrastructure with ignored tokio tests and bash replication scripts.

10|1|Updated Jul 7, 2026
One-click install
npx skills add https://github.com/catalystctl/catcode --skill e2e-test-core-tool-catalystctl
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: e2e-test-core-tool
Source: https://github.com/catalystctl/catcode/tree/main/.catalyst-code/skills/e2e-test-core-tool
Command: npx skills add https://github.com/catalystctl/catcode --skill e2e-test-core-tool-catalystctl

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Unit tests of pure logic do not prove that a tool which shells out to real processes (containers, VMs, SSH, QEMU) actually works against live infrastructure. This Skill provides a rigorous workflow to exercise a tool's real code path end-to-end and report honestly what was and was not verified. ## Core Features & Use Cases - Host Dependency Probing: Checks that runtime dependencies (podman, qemu-system-x86_64, swtpm, websockify, /dev/kvm) exist before promising e2e coverage. - Bash Replication Scripts: Replays the exact argv sequence the Rust tool builds to validate infrastructure and command shapes with clear PASS/FAIL per step. - Ignored Tokio Dispatch Tests: Adds #[ignore] #[tokio::test] tests calling the real execute_<tool> against live infra, with drop guards that clean up resources even on panicking asserts. - Honest Verification Reports: Documents what passed, bugs found and fixed, and explicitly what remains untested. - Use Case: After adding a new container-management tool in core/src/tools.rs, run this workflow to build the image, replicate commands in bash, run the ignored Rust test with cargo test --bin core <tool> -- --ignored --nocapture, and produce a truthful e2e report. ## Quick Start Ask the agent to e2e test the new core tool you just added, probing host dependencies, writing a bash replication script, and running an ignored tokio test against live infrastructure.

Frequently Asked Questions about e2e-test-core-tool

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I e2e test a Rust tool that spawns real processes?

Probe host dependencies first, build the real artifact, write a bash script replicating the exact command sequence, then add an #[ignore] #[tokio::test] calling the real execute function against live infrastructure. Run it with cargo test --bin core <tool> -- --ignored --nocapture.

How do I run only ignored tests in a Rust binary?

Use cargo test --bin core <name> -- --ignored --nocapture. The --ignored flag runs only tests marked #[ignore], filtered by name, avoiding parallel env-var races with the rest of the suite.

Why does localhost fail with rootless podman port forwarding?

Rootless podman's pasta/slirp4netns forwarder listens on IPv4 only, so localhost resolving to ::1 fails. Use 127.0.0.1 in any URL a browser or curl connects to.

How do I clean up test resources when a Rust assertion panics?

Use a drop guard: a struct holding the resource ID whose Drop implementation runs the cleanup command (e.g. podman rm -f). Disarm the guard after explicit destroy so cleanup only fires on early failure.

When is a unit test not enough for tool verification?

Unit tests of pure logic never exercise the real code path against real infrastructure. Tools that shell out to containers, VMs, SSH, or QEMU need e2e tests against live dependencies to catch bugs in command shapes and output parsing.