tmt-e2e

Add, run, and diagnose Docker-isolated end-to-end tests for the tmt CLI and tmux.

11|Updated Dec 17, 2025
One-click install
npx skills add https://github.com/wkh237/tmux-team --skill tmt-e2e-wkh237
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tmt-e2e
Source: https://github.com/wkh237/tmux-team/tree/main/.agents/skills/tmt-e2e
Command: npx skills add https://github.com/wkh237/tmux-team --skill tmt-e2e-wkh237

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? End-to-end testing of a tmux-orchestrating CLI is risky: tests can leak tmux servers, touch host credentials, or pass without the intended action occurring. This Skill enforces a Docker-isolated E2E boundary so tmt and tmux are exercised for real without endangering the host environment. ## Core Features & Use Cases - Docker-isolated test execution: Run the real tmt CLI and a real tmux server inside a network-isolated container via the run-e2e.mjs wrapper, with Vitest as the scenario runner. - Deterministic mock agents: Drive mock agents inside tmux panes as deterministic peers, never invoking real AI models, credentials, or network services. - Quality gate enforcement: Apply rules for causal assertions, bounded polling, cleanup verification, negative-path coverage, and CLI selection validation. - Use Case: When adding a lifecycle or cleanup change to tmt, use this Skill to write a scenario that proves teardown is idempotent by running the Docker suite twice and verifying observable absence of leaked state. ## Quick Start Ask the agent to add a Docker E2E scenario for a tmt CLI behavior and run it through the repository's documented run-e2e.mjs command.

Frequently Asked Questions about tmt-e2e

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

FAQPage Schema
How do I run end-to-end tests for a tmux-based CLI in Docker?

Use the repository's documented E2E command through typescript/scripts/run-e2e.mjs, which builds and runs the Docker container. Vitest acts as the scenario runner and assertion layer while Docker provides network and host isolation.

How do I test a CLI that drives tmux panes without a real AI agent?

Run deterministic mock agents inside tmux panes as peers of the real tmt CLI. Never invoke a real AI model, credential, or network service; assert on agent-produced output corroborated by the structured event log or metadata.

Should E2E tests for tmt use the host tmux server?

No. Tests must never touch the host user's tmux server, host credentials, or unrelated processes. The container must be network-isolated, and every scenario must clean up its temporary tmux server, socket, panes, and files even on failure.

Why do tmux E2E tests pass without the action actually happening?

Terminal-echoed input is not proof a mock agent processed a request. Wait for agent-produced output and corroborate it with the structured event log; a test that can pass without the intended action is a test bug and must be fixed first.

How do I verify cleanup and lifecycle changes in tmux E2E tests?

Run the Docker suite twice to catch leaked state and non-idempotent teardown. Verify cleanup with observable absence of servers, sockets, and files rather than only calling a cleanup function, and use read-only SQL snapshots for ordering proofs.