# Test Runner

> Écrit et exécute les tests pour valider l'implémentation. Priorités P0-P3, risk-based, avec web-navigator/Playwright CLI pour explorer les apps web runtime avant E2E. Utilisé depuis /dev ou standalone.

- Skill: `elsolal/test-runner` (Agent Skill)
- Install (CLI): `npx skillmds@latest add elsolal/test-runner`
- Raw SKILL.md: https://api.skillmd.com/api/skills/elsolal/test-runner/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: elsolal (https://skillmd.com/u/elsolal)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/elsolal/test-runner

---


# Test Runner

## Rôle

Test Architect qui conçoit et exécute une stratégie de test risk-based.

## Principes

- **Risk-based testing** — Profondeur des tests proportionnelle à l'impact business
- **Tests = documentation** — Un bon test explique le comportement attendu
- **Déterminisme absolu** — Pas de flaky tests, pas de hard waits
- **Isolation stricte** — Chaque test nettoie après lui
- **Fail fast** — P0 d'abord, arrêter si critique échoue

## Règles

- Ne JAMAIS utiliser `waitForTimeout()` — utiliser `waitForResponse()` ou état élément
- Ne JAMAIS passer à la review avec tests échouant
- Ne JAMAIS cacher des assertions dans des helpers
- Toujours tagguer les tests par priorité (@p0, @p1, @p2, @p3)

---

## Navigation runtime avant E2E

Quand le scope inclut une app web runtime, charger `web-navigator` avant d'ecrire les E2E. Ce skill pilote la navigation via Playwright CLI, Browser/MCP ou fallback web, puis restitue les preuves: ouverture d'URL, clics, formulaires, screenshots, console, reseau, storage et locators.

Installation recommandee sur la machine de l'agent:

```bash
npm install -g @playwright/cli@latest
playwright-cli install --skills
playwright-cli --help
```

Utiliser `web-navigator` pour explorer et capturer les preuves; convertir ensuite les flows critiques en tests Playwright versionnes et determinants.

## Priorités P0-P3

| Priorité | Critères | Coverage cible |
|----------|----------|----------------|
| **P0** | Revenue-critical, Security, Data integrity | Unit >90%, Int >80%, E2E all paths |
| **P1** | Core user journeys, Complex logic | Unit >80%, Int >60%, E2E happy paths |
| **P2** | Secondary features, Admin | Unit >60%, Int >40%, Smoke |
| **P3** | Rarely used, Nice-to-have | Best effort |

---

## Process

### 1. Analyser et prioriser
- Détecter le framework de test (Jest, Vitest, Pytest, etc.)
- Classifier chaque fonctionnalité par priorité P0-P3
- Choisir le bon niveau : Unit / Integration / E2E / Component
- Si UI web runtime, utiliser `web-navigator` pour confirmer le flow, extraire les locators et capturer console/reseau avant d'ecrire l'E2E

### 2. Écrire les tests

**Naming :** `should_[comportement]_when_[condition]`

**Pattern Arrange-Act-Assert :**
```typescript
describe('[Module]', () => {
  it('should [comportement] when [condition] @p0', () => {
    // Arrange
    const user = createUser({ email: faker.internet.email() });
    // Act
    const result = await createOrder(user.id, cart);
    // Assert
    expect(result.status).toBe('created');
  });
});
```

### 3. Exécuter et valider

```bash
# P0 d'abord (smoke)
npm test -- --grep @p0

# P0 + P1 (core)
npm test -- --grep "@p0|@p1"

# Full regression
npm test
```

### 4. Vérifier le déterminisme
- 3 runs successifs identiques (pas de flaky)
- Si flaky → charger knowledge debugging

---

## Gestion des échecs

| Symptôme | Cause probable | Fix |
|----------|----------------|-----|
| Timeout aléatoire | Hard wait | `waitForResponse()` |
| Element not found | Race condition | Network-first pattern |
| Data collision | Hardcoded IDs | Faker + cleanup |

---

## Quality Checklist

```markdown
### Tests: [Feature]

**Déterminisme**
- [ ] Pas de hard waits (`waitForTimeout`)
- [ ] Pas de conditionnels (if/else dans tests)
- [ ] Données uniques (faker)

**Qualité**
- [ ] Tests < 300 lignes
- [ ] Tests < 1.5 minutes
- [ ] Assertions explicites
- [ ] Cleanup automatique

**Coverage par priorité**
- [ ] P0: Unit >90%, Int >80%
- [ ] P1: Unit >80%, Int >60%

**Exécution**
- Commande: `npm test`
- Résultat: ? X passed / ? X failed
- Flaky check: 3 runs identiques ?
```