ln-404-test-executor
Scannednpx machina-cli add skill levnikolaevich/claude-code-skills/ln-404-test-executor --openclawTest Task Executor
Runs a single Story final test task (label "tests") through implementation/execution to To Review.
Purpose & Scope
- Handle only tasks labeled "tests"; other tasks go to ln-401.
- Follow the 11-section test task plan (E2E/Integration/Unit, infra/docs/cleanup).
- Enforce risk-based constraints: Priority ≥15 scenarios covered; each test passes Usefulness Criteria; no framework/DB/library/performance tests.
- Update Linear/kanban for this task only: Todo -> In Progress -> To Review.
Task Storage Mode
| Aspect | Linear Mode | File Mode |
|---|---|---|
| Load task | get_issue(task_id) | Read("docs/tasks/epics/.../tasks/T{NNN}-*.md") |
| Load Story | get_issue(parent_id) | Read("docs/tasks/epics/.../story.md") |
| Update status | update_issue(id, state) | Edit the **Status:** line in file |
| Test results | Linear comment | Append to task file |
File Mode transitions: Todo → In Progress → To Review
Workflow (concise)
- Receive task: Get task ID from orchestrator (ln-400); fetch full test task description (Linear: get_issue; File: Read task file); read linked guides/manuals/ADRs/research; review parent Story and manual test results if provided.
1b) Goal gate: MANDATORY READ:
shared/references/goal_articulation_gate.md— State REAL GOAL of these tests (which business behavior must be verified, not "write tests"). NOT THE GOAL: testing infrastructure or framework behavior instead of business logic. HIDDEN CONSTRAINT: which existing tests might break from implementation changes. - Read runbook: Read
docs/project/runbook.md— understand test environment setup, Docker commands, test execution prerequisites. Use exact commands from runbook. - Validate plan: Check Priority ≥15 coverage and Usefulness Criteria; ensure focus on business flows (no infra-only tests).
- Start work: Set task In Progress (Linear: update_issue; File: Edit status line); move in kanban.
- Implement & run: Author/update tests per plan; reuse existing fixtures/helpers; run tests; fix failing existing tests; update infra/doc sections as required.
- Complete: Ensure counts/priority still within limits; set task To Review; move in kanban; add comment summarizing coverage, commands run, and any deviations.
Critical Rules
- Single-task only; no bulk updates.
- Do not mark Done; ln-402 approves. Task must end in To Review.
- Keep language (EN/RU) consistent with task.
- No framework/library/DB/performance/load tests; focus on business logic correctness (not infrastructure throughput).
- Respect limits and priority; if violated, stop and return with findings.
- Do NOT commit. Leave all changes uncommitted — ln-402 reviews and commits with task ID reference.
Definition of Done
- Task identified as test task and set to In Progress; kanban updated.
- Plan validated (priority/limits) and guides read.
- Tests implemented/updated and executed; existing failures fixed.
- Docs/infra updates applied per task plan.
- Task set to To Review; kanban moved; summary comment added with commands and coverage.
Test Failure Analysis Protocol
CRITICAL: When a newly written test fails, STOP and analyze BEFORE changing anything (failing new tests often indicate implementation bugs, not test issues — fixing blindly masks root cause).
Step 1: Verify Test Correctness
- Does test match AC requirements exactly? (Given/When/Then from Story)
- Is expected value correct per business logic?
- If uncertain: Query
ref_search_documentation(query="[domain] expected behavior")
Step 2: Decision
| Test matches AC? | Action |
|---|---|
| YES | BUG IN CODE → Fix implementation, not test |
| NO | Test is wrong → Fix test assertion |
| UNCERTAIN | MANDATORY: Query MCP Ref + ask user before changing |
Step 3: Document in Linear comment "Test [name] failed. Analysis: [test correct / test wrong]. Action: [fixed code / fixed test]. Reason: [justification]"
RED FLAGS (require user confirmation):
- ⚠️ Changing assertion to match actual output ("make test green")
- ⚠️ Removing test case that "doesn't work"
- ⚠️ Weakening expectations (e.g.,
toContaininstead oftoEqual)
GREEN LIGHTS (safe to proceed):
- ✅ Fixing typo in test setup/mock data
- ✅ Fixing code to match AC requirements
- ✅ Adding missing test setup step
Test Writing Principles
1. Strict Assertions - Fail on Any Mismatch
Use exact match assertions by default:
| Strict (PREFER) | Loose (AVOID unless justified) |
|---|---|
| Exact equality check | Partial/substring match |
| Exact length check | "Has any length" check |
| Full object comparison | Partial object match |
| Exact type check | Truthy/falsy check |
WARN-level assertions FORBIDDEN - test either PASS or FAIL, no warnings.
2. Expected-Based Testing for Deterministic Output
For deterministic responses (API, transformations):
- Use snapshot/golden file testing for complex deterministic output
- Compare actual output vs expected reference file
- Normalize dynamic data before comparison (timestamps → fixed, UUIDs → placeholder)
3. Golden Rule
"If you know the expected value, assert the exact value."
Forbidden: Using loose assertions to "make test pass" when exact value is known.
Reference Files
- Kanban format:
docs/tasks/kanban_board.md
Version: 3.2.0 Last Updated: 2026-01-15
Source
git clone https://github.com/levnikolaevich/claude-code-skills/blob/master/ln-404-test-executor/SKILL.mdView on GitHub Overview
ln-404-test-executor runs Story Finalizer test tasks labeled “tests” from Todo through In Progress to To Review. It enforces risk-based limits, prioritization, and updates the kanban state while focusing on business logic validation rather than infrastructure.
How This Skill Works
The skill loads the task (Linear: get_issue; File: Read task file), reads the Story and relevant guides, and enforces the mandatory goal articulation gate and runbook guidance. It validates plan constraints (priority, usefulness), marks the task In Progress, implements/updates tests, runs them, and finally moves the task to To Review with a summary of coverage and deviations.
When to Use It
- When a task labeled "tests" exists in Todo and must move to In Progress before execution.
- When enforcing Priority ≥ 15 and Usefulness Criteria for test tasks to ensure business-focused validation.
- When following the 11-section test task plan (E2E/Integration/Unit, infra/docs/cleanup).
- When you must avoid bulk updates and keep changes uncommitted (ln-402 compliance).
- When updating or documenting test coverage, commands run, and any deviations before final To Review.
Quick Start
- Step 1: Fetch the test task from the orchestrator and load the task description, Story, and guides.
- Step 2: Gate the task with the Goal Articulation Gate and read the runbook; validate plan constraints.
- Step 3: Set In Progress, implement/update tests, run them, then move to To Review with a coverage summary.
Best Practices
- Always load the full test task description, linked guides, and the parent Story before implementing tests.
- Read and apply the mandatory goal articulation gate to state the REAL business goal.
- Use existing fixtures/helpers and exact runbook commands; minimize new infra changes.
- Limit changes to a single task per run; no bulk updates to multiple tasks.
- Document coverage, commands executed, and any deviations in the summary comment.
Example Use Cases
- A test task validates the Story Finalizer handles a successful checkout path and moves from Todo -> In Progress -> To Review.
- A test task verifies error handling when a payment gateway times out, ensuring business flow remains consistent.
- A test task checks a boundary case where a discount is applied and must still pass Usefulness Criteria.
- A test task confirms that the To Review state reflects correct Kanban updates after test execution.
- A test task cross-checks that no infra-only tests are executed and business logic remains intact.
