dev-test

What this skill does

## Where This Fits

```
Main Chat                          Task Agent
─────────────────────────────────────────────────────
/goal <condition> (set at phase entry; refires turns)
dev-implement (loads dev-tdd)
  → dev-delegate
    → Task agent ──────────────────→ uses dev-test (this skill)
                                       ↓ loads dev-tdd again
                                     has TDD protocol + gates
                                       → routes to specific tool
```

<EXTREMELY-IMPORTANT>
## Load TDD Enforcement (REQUIRED)

Before choosing testing tools, you MUST load the TDD skill to ensure gate compliance:

Read `${CLAUDE_SKILL_DIR}/../../skills/dev-tdd/SKILL.md` and follow its instructions.

This loads:
- Task reframing (your job is writing tests, not features)
- **The Execution Gate** (6 mandatory gates before E2E testing)
- **GATE 5: READ LOGS** (mandatory - cannot skip)
- The Iron Law of TDD (test-first approach)

**Read dev-tdd skill content now before selecting testing tools.**
</EXTREMELY-IMPORTANT>

**This skill routes to the right testing tool.** The loaded `dev-tdd` skill provides TDD protocol details.

## Contents

- [The Iron Law](#the-iron-law-of-testing)
- [Browser Testing Decision Tree](#browser-testing-decision-tree)
- [Platform Detection](#platform-detection)
- [Sub-Skills Reference](#sub-skills-reference)
- [Unit & Integration Tests](#unit--integration-tests)

<EXTREMELY-IMPORTANT>
## The Iron Law of Testing

**YOU MUST WRITE E2E TESTS FOR USER-FACING FEATURES. This is not negotiable.**

When your changes affect what users see or interact with, you MUST:
1. Write an E2E test that simulates user behavior
2. Run it and verify it PASSES (not just unit tests)
3. Document: "E2E: [test name] passes with [evidence]"
4. Include screenshot/snapshot for visual changes

**Unit tests prove components work. E2E tests prove YOUR feature works for users.**

### Rationalization Prevention

When you catch yourself thinking these rationalizations, STOP—you're about to skip E2E tests:

| Thought | Why You're Wrong | Do Instead |
|---------|-----------------|-----------|
| "Unit tests are enough" | Your unit tests don't test user flows. | Write E2E. |
| "E2E is too slow" | You're choosing slow tests < shipped bugs. | Write E2E. |
| "I'll add E2E later" | You won't. Your future self won't either. | Write it NOW. |
| "This is just backend" | Does it affect user output? Then YOU need E2E. | Write E2E. |
| "The tool setup is complex" | Your complexity = complex failure modes. E2E finds them. | Write E2E. |
| "The UI is unchanged" | Your assumption isn't proven. | Prove it with a visual snapshot. |
| "Manual testing is faster" | You're creating false confidence — manual testing misses regressions. | Write E2E. |
| "It's just a small change" | Your small change breaks UIs. E2E proves it doesn't. | Write E2E. |
| "User can verify" | NO. You don't trust users with QA. | Automated verification or it didn't happen. |
| **"Log checking is my E2E test"** | **You're confusing observability with verification.** | **Verify your actual outputs.** |
| **"Screenshots are too hard to capture"** | **Your avoidance = hard to debug in production later.** | **Automate it.** |

### Fake E2E Detection - STOP

**If your "E2E test" does any of these, it's NOT E2E:**

| Pattern | Why It's Fake | Real E2E Alternative |
|---------|---------------|----------------------|
| `grep "success" logs.txt` | Only proves code ran | Verify actual output file/UI/API response |
| `assert mock.called` | Tests mock, not real system | Use real integration, verify real data |
| `cat output.txt \| wc -l` | File exists ≠ correct content | Read file, assert exact expected content |
| "I ran it manually" | No automation = no evidence | Capture manual test as automated test |
| Check log for icon name | Observability, not verification | Screenshot + visual diff of rendered icon |
| Exit code 0 | Process succeeded ≠ output correct | Verify the actual output data |

**The test:** If removing the actual implementation still passes your "E2E test", it's fake.

**Example of fake E2E that caught nothing:**
```python
# FAKE E2E - only checks logs
def test_icon_theme_change():
    run_command("set-theme papirus")
    logs = read_logs()
    assert "papirus" in logs  # ❌ FAKE - only proves code ran
    # BUG: 89% of icons weren't changed, test still passed!
```

**Real E2E that would have caught the bug:**
```python
# REAL E2E - verifies actual output
def test_icon_theme_change():
    run_command("set-theme papirus")
    screenshot = capture_desktop()
    assert visual_diff(screenshot, "expected_papirus.png") < threshold  # ✅ REAL
    # This would have shown 89% of icons were wrong
```

### Red Flags - STOP If Thinking:

If you catch yourself thinking these patterns, STOP—you're about to skip E2E:

| Thought | Why You're Wrong | Do Instead |
|---------|-----------------|-----------|
| "Tests pass" (only unit) | Your unit tests ≠ E2E | Write E2E test |
| "Code looks correct" | You're only looking ≠ running user flow | Run E2E |
| "It worked when I tried it" | Your manual testing ≠ automated | Capture as E2E |
| "Screenshot shows it works" | Your static screenshot ≠ interaction test | Add automation |
</EXTREMELY-IMPORTANT>

## Browser Testing Decision Tree

```
┌─────────────────────────────────────────────────────────────────┐
│                    BROWSER TESTING REQUIRED?                     │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
        ┌─────────────────────────────────────────────┐
        │  Need to debug JS errors or API calls?       │
        │  (console.log, network requests, XHR)        │
        └─────────────────────────────────────────────┘
                    │                    │
                   YES                   NO
                    │                    │
                    ▼                    ▼
        ┌───────────────────┐  ┌──────────────────────────┐
        │   CHROME MCP      │  │  Running in CI/CD?        │
        │   (debugging)     │  │  (headless, automated)    │
        └───────────────────┘  └──────────────────────────┘
                                      │           │
                                     YES          NO
                                      │           │
                                      ▼           ▼
                        ┌──────────────┐  ┌───────────────────┐
                        │ PLAYWRIGHT   │  │ Cross-browser     │
                        │ MCP          │  │ needed?           │
                        └──────────────┘  └───────────────────┘
                                                │          │
                                               YES         NO
                                                │          │
                                                ▼          ▼
                                    ┌──────────────┐ ┌────────────┐
                                    │ PLAYWRIGHT   │ │ Either OK  │
                                    │ MCP          │ │ (prefer    │
                                    └──────────────┘ │ Playwright)│
                                                     └────────────┘
```

<EXTREMELY-IMPORTANT>
### Iron Laws: Browser MCP Selection

**YOU MUST USE CHROME MCP FOR API/CONSOLE DEBUGGING. NO EXCEPTIONS.**
**YOU MUST USE PLAYWRIGHT MCP FOR CI/CD TESTING. NO EXCEPTIONS.**

### Quick Decision Table

| Need | Tool | Why |
|------|------|-----|
| Debug console errors | **Chrome MCP** | `read_console_messages` |
| Inspect API calls/responses | **Chrome MCP** | `read_network_requests` |
| Execute custom JS in page | **Chrome MCP** | `javascript_tool` |
| Record interaction as GIF | **Chrome MCP** | `gif_creator` |
| Headless/CI automation | **Playwright MCP** | Headless mode |
| Cross-browser testing | **Playwright MCP** | Firefox/WebKit support |
| Standard E2E suite | **Playwright MCP** | Test