> fais-moi un module de facturation

 invoice.ts | 312 ++++++++++
 tax.ts | 208 ++++++++
 pdf.ts | 176 ++++++--
 webhooks.ts | 143 +++++-
 ... + 43 autres fichiers
 47 fichiers, +1 240 −287

## Quand MOI et pas X

- MOI quand : code existant sans tests suffisants · objectif = couvrir du code déjà écrit
- test-sweep : audit global de couverture sur tout le projet
- feature-implementation-vue-nuxt / feature-implementation-rust-axum : feature pas encore implémentée (les tests font partie de l'implémentation)

> Règle rapide : code existe, tests manquent = MOI.

---

# Write Tests - Expert ISTQB Testing Skill

Expert ISTQB Foundation v4.0. `$ARGUMENTS` = le sujet, fichier ou feature à tester.

## 1. GOLDEN DATASET

Avant tout test E2E, vérifier que le dataset est chargé :
```bash
psql "$DATABASE_URL" -c "SELECT count(*) FROM checks WHERE id LIKE 'cccccccc%'"
```
Si count = 0, charger :
```bash
psql "$DATABASE_URL" -f test-data/golden-dataset.sql
```

### IDs de référence (figés · JAMAIS de données magiques)

| Entité | ID | État | Description |
|--------|-----|------|-------------|
| Org | `f32c735c-...` | - | Granit Labs |
| User | `bb5562b9-...` | - | test@granit.local / Password123 |
| Project Prod | `a1b2c3d4-1234-5678-9abc-def012345678` | production | Production API |
| Project Staging | `b2c3d4e5-2345-6789-abcd-ef0123456789` | staging | Staging Environment |
| Check Google | `d4e5f6a7-4567-89ab-cdef-012345678901` | passing | Google Homepage |
| Check GitHub | `e5f6a7b8-5678-9abc-def0-123456789012` | passing | GitHub API |
| Check Payment | `cccccccc-0001-0001-0001-000000000001` | failing | Payment API (12 failures consécutifs) |
| Check Staging DB | `cccccccc-0001-0001-0001-000000000002` | failing | Staging DB (5 failures) |
| Check CDN | `cccccccc-0001-0001-0001-000000000003` | warning | CDN Edge (lent) |
| Check Legacy | `cccccccc-0001-0001-0001-000000000004` | snoozé | Legacy API (snoozé 2h) |
| Alerts `eeeeeeee-...-0000000000` | `01` firing (Payment), `02` firing (Staging DB), `03` acknowledged (CDN), `04` resolved (Google 3j), `05` resolved (GitHub 7j), `06` resolved (Payment 30j) | | |
| Channels `ffffffff-0002-...-1/2/3` | actifs : Email, Slack, Webhook | | |
| Rules `ffffffff-0001-...-1/2/3` | actifs sur Payment, Staging DB, CDN | | |

---

## 3. NIVEAUX DE TEST (ISTQB v4.0)

| Niveau | Scope | Qui | Défauts typiques | Approche |
|--------|-------|-----|-----------------|----------|
| Unit | Fonction/classe isolée | Dev | Logique, boundaries | White-box, stubs |
| Intégration | Interfaces entre composants | Dev/QA | Mismatch API, mapping data | API contracts |
| Système (E2E) | Système complet | QA | Flux cassés, cross-fonctionnel | Black-box, golden dataset |
| Acceptation | Validation business | PO/User | Workflow gaps, compliance | UAT, Gherkin |

---

## 4. TECHNIQUES DE CONCEPTION (ISTQB)

Black-box : Equivalence Partitioning (classes d'inputs : <0 invalide / 0-100 valide / >100 invalide) · Boundary Value Analysis (frontières : seuil 100ms → 99, 100, 101) · Decision Table (conditions combinées) · State Transition (Alert: firing → acknowledged → resolved) · Use Case Testing (flux utilisateur).

White-box : Statement Coverage ≥80% · Branch Coverage ≥80% (recommandé ISTQB) · Path Coverage (code critique uniquement).

Experience-based : Error Guessing (null, vide, négatif, SQL injection, XSS) · Exploratory (sessions 60-120min avec charter) · Checklist-based (régression par feature).

---

## 5. PRINCIPES FIRST

| Principe | Règle |
|----------|-------|
| Fast | Unit < 1ms, suite < 10s · pas de DB, pas de réseau |
| Isolated | Pas d'état partagé mutable · setup/teardown indépendant par test |
| Repeatable | Même résultat partout · pas de dépendance horloge/réseau/random |
| Self-validating | Pass ou Fail · assertions claires, pas "check les logs" |
| Timely | Écrire avec le code (TDD ou test-alongside), pas après |

---

## 6. RÈGLES ABSOLUES (projet Granit Golem)

1. `data-testid` : TOUJOURS pour les locators E2E. JAMAIS `text=`, CSS class, XPath
2. Page Object Pattern : séparer locators / actions / assertions
3. ZERO `waitForTimeout` : attendre un état concret (`waitFor({ state: 'visible' })`, URL, response)
4. Scoped locators : `parent.getByTestId('child')` jamais `page.getByTestId('child')` global
5. Golden Dataset : utiliser les IDs de référence, JAMAIS de données magiques
6. Pas de `test.skip()` conditionnel : le golden dataset garantit les données
7. AAA Pattern : Arrange → Act → Assert, un seul `act` par test
8. Un concept par test : si "and" dans le nom, split

---

## 7. ANTI-PATTERNS

- waitForTimeout → `await element.waitFor({ state: 'visible' })`
- Flaky → waits explicites, isolation, mock external
- Test coupling (B fail si A absent) → setup indépendant par test
- Over-mocking (tests verts, prod casse) → mock aux frontières, pas les internes
- Tester l'implémentation (refacto casse sans changer le comportement) → tester le comportement public
- The Liar (test sans assertion) → chaque test DOIT pouvoir échouer
- Giant Test / Copy-paste → un concept par test, page objects/helpers/fixtures

---

## 8. EXEMPLES MINIMAUX

E2E · locators scopés + wait sur état (Page Object) :
```typescript
const locators = {
 heading: page.getByTestId('feature-heading'),
 item: page.getByTestId('feature-item'),
 // SCOPED : dropdown DANS un item
 itemAction: page.getByTestId('feature-item').getByTestId('dropdown-trigger'),
}
async goto() {
 await page.goto('/dashboard/feature')
 await locators.heading.waitFor({ state: 'visible', timeout: 10000 })
}
```

E2E · spec AAA, un seul act :
```typescript
test('should display items from golden dataset', async ({ page }) => {
 const featurePage = createFeaturePage(page) // Arrange
 await featurePage.goto()
 // Act : aucun (vérif d'affichage)
 expect(await featurePage.getItemCount()).toBeGreaterThan(0) // Assert
})
```
Login partagé via `test.beforeEach` (`createLoginPage` + `testConfig.seedUser`).

Intégration API :
```typescript
test('GET /feature returns items', async ({ request }) => {
 const ctx = await request.newContext({ baseURL: 'http://localhost:3000/api/v1' })
 const response = await ctx.get('/feature') // Act
 expect(response.status()).toBe(200) // Assert
 expect((await response.json()).data.length).toBeGreaterThan(0)
})
```

Unitaire Rust (cas valide + cas d'erreur séparés) :
```rust
#[test]
fn should_reject_inverted_thresholds() {
 let result = validate_thresholds(1000, 500); // Arrange + Act
 assert!(result.is_err()); // Assert
 assert_eq!(result.unwrap_err().to_string(), "Warning threshold must be less than critical");
}
```

---

## 9. EXÉCUTION DU SKILL

1. Analyser le fichier/feature cible dans `$ARGUMENTS`
2. Classifier le type (E2E / intégration / unitaire)
3. Concevoir avec les techniques ISTQB (EP, BVA, State Transition...)
4. Préparer : ajouter les `data-testid` dans les composants Vue si besoin
5. Implémenter : page object dans `e2e/pages/` + test spec
6. Vérifier : lancer le test, corriger jusqu'à vert

---

## 10. CONDITION DE SORTIE

Terminé SEULEMENT quand :
- [ ] Tous les tests écrits passent (`npx playwright test e2e/XX-nom.spec.ts` / `vitest run` / `cargo test`)
- [ ] `data-testid` ajoutés, page object créé/à jour dans `e2e/pages/`
- [ ] Locators scopés au bon contexte, golden dataset référencé (pas de données magiques)
- [ ] Pattern AAA respecté, un concept par test
- [ ] ZERO `waitForTimeout`, ZERO sélecteur `text=` ou CSS class fragile

NE PAS déclarer terminé si un test est skipped, flaky ou commenté "à corriger plus tard".