e2e-test-thinker

Analyzes branch diffs and plans CLI-based end-to-end test coverage for UniClipboard.

1.6k|73|Updated Mar 13, 2025
One-click install
npx skills add https://github.com/UniClipboard/UniClipboard --skill e2e-test-thinker
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: e2e-test-thinker
Source: https://github.com/UniClipboard/UniClipboard/tree/main/.agents/skills/e2e-test-thinker
Command: npx skills add https://github.com/UniClipboard/UniClipboard --skill e2e-test-thinker

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Deciding whether a code change needs end-to-end test coverage—and writing those tests correctly against a black-box CLI harness—is time-consuming and error-prone. This Skill automates the analysis of your branch's diff against main and produces a concrete, runnable e2e test plan.

Core Features & Use Cases

  • Diff Classification: Categorizes every changed file as CLI-testable, GUI-only, build/docs-only, or internal refactor, so you know exactly what deserves e2e coverage.
  • Coverage Gap Detection: Greps the existing tests/e2e/ suite to identify which changes are already covered and which are not.
  • Test Case Sketches: Generates ready-to-review Rust test sketches using TestProfile, TestDaemon, and TestCli with proper isolation, JSON assertions, and file placement recommendations.
  • Use Case: After finishing a feature that adds a new uniclip subcommand, ask for an e2e analysis before opening your PR—you get a structured plan listing covered items, untestable items, and proposed test functions to confirm.

Quick Start

Ask the assistant to analyze the current branch's changes and propose an end-to-end test plan using the uc-e2e-tests harness.

Frequently Asked Questions about e2e-test-thinker

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

FAQPage Schema
How do I plan end-to-end tests for a CLI application?

Start by diffing your branch against main, then classify each change as CLI-testable, GUI-only, or internal. For testable items, write black-box tests that spawn the daemon, run CLI subcommands, and assert on exit codes and JSON output.

How do I check if my changes already have e2e test coverage?

Grep the existing test directory for the relevant command names or keywords, for example `grep -r "keyword" tests/e2e/tests/`. Compare matches against your changed files to identify uncovered behavior before writing new tests.

What changes should not get end-to-end tests?

Skip e2e tests for GUI-only changes like React components or Tauri commands, docs/CI/build changes, and internal refactors where existing tests already provide regression coverage. Those belong in unit, integration, or GUI test layers.

Why are my CLI e2e tests flaky when run in parallel?

Flakiness usually comes from shared state between tests. Each test must use a unique isolated profile with its own data directory, socket, and identity, and should avoid sleep-based timing in favor of polling with a deadline.

Should I assert on human-readable CLI output in tests?

No, avoid exact string matching on human-readable output since formatting changes break tests. Use the CLI's --json flag and parse the structured output with serde_json to assert on specific fields and schema.