Testing

Testing - Principes TDD/BDD (2026)

Principes universels de testing pour toutes les technologies du framework Claude-Craft.

Principes fondamentaux

• TDD Cycle: RED → GREEN → REFACTOR
• Couverture cible: >= 80%
• Pyramide: Unit (70%) > Integration (20%) > E2E (10%)
• Pattern: Arrange-Act-Assert (AAA)
• Nommage: Tests descriptifs expliquant le comportement

Outils recommandés 2026

Sources : Vitest 4, Pest 4, Stryker Mutator

Stratégies 2026

Vitest 4 — Browser Mode stable

Abandonner JSDOM lourd. Chromium/Firefox/WebKit natifs.

// vitest.config.ts
export default defineConfig({
  test: {
    browser: {
      enabled: true,
      name: 'chromium', // ou 'firefox', 'webkit'
      provider: 'playwright',
    },
  },
});

Source : Vitest Browser Mode

Mutation Testing — "Coverage ment, mutation scores disent la vérité"

Tester la qualité des tests. Mutation score >= 80%.

# Stryker (JS/TS/C#)
npx stryker run

# Infection (PHP)
vendor/bin/infection --min-msi=80

# Mutmut (Python)
mutmut run

Source : Stryker Mutator

Property-based Testing

Générer des tests à partir de propriétés invariantes.

// fast-check (JS/TS)
import fc from 'fast-check';

test('sorting preserves all elements', () => {
  fc.assert(
    fc.property(fc.array(fc.integer()), (arr) => {
      const sorted = [...arr].sort();
      return sorted.length === arr.length;
    })
  );
});

Source : fast-check

Pest 4 — Browser Testing intégré

// Pest 4.5+ avec Playwright natif
test('user can login', function () {
    $this->browse(function (Browser $browser) {
        $browser->visit('/login')
            ->type('email', 'alice@example.com')
            ->type('password', 'secret')
            ->press('Login')
            ->assertPathIs('/dashboard');
    });
});

Source : Pest 4 Browser Testing

Vitest Workspaces — Monorepos

// vitest.workspace.ts
export default defineWorkspace([
  'packages/*/vitest.config.ts', // Unit tests
  {
    test: {
      browser: { enabled: true, name: 'chromium' },
      include: ['e2e/**/*.test.ts'],
    },
  }, // Browser tests
]);

Source : Vitest Workspaces

---

Voir @.claude/references/base/testing.md pour documentation complète.

Testing - TDD/BDD Principles

Universal TDD/BDD testing principles, best practices, and anti-patterns for any technology stack.

Part of Claude-Craft -- AI-assisted development framework for Claude Code.

Installation

Copy this directory to your project's .claude/skills/ directory:

cp -r testing/ your-project/.claude/skills/testing/

What's Included

• SKILL.md -- Skill definition with triggers and quick reference
• REFERENCE.md -- Comprehensive testing guidelines covering TDD, BDD, test pyramid, best practices, and anti-patterns

Covers

• Test-Driven Development (TDD) -- Red/Green/Refactor cycle
• Behavior-Driven Development (BDD) -- Given/When/Then with Gherkin
• Test pyramid -- unit (70%), integration (20%), E2E (10%)
• Best practices -- AAA pattern, naming conventions, test independence
• Anti-patterns -- flaky tests, implementation testing, commented tests

Technology Agnostic

This skill provides universal testing principles applicable to any language and testing framework. It does not prescribe specific tools -- adapt the principles to your stack's ecosystem.

License

MIT -- See Claude-Craft for full license.

Testing - Principes TDD/BDD

Vue d'ensemble

Le Test-Driven Development (TDD) et le Behavior-Driven Development (BDD) sont des pratiques obligatoires pour garantir la qualité et la maintenabilité du code.

Note: Ce document présente les principes généraux. Consultez les règles spécifiques à votre technologie pour les outils et frameworks concrets.

Objectifs:

• ✅ Couverture de code ≥ 80%
• ✅ Tests rapides (< 10s pour les unitaires)
• ✅ Tests indépendants et reproductibles
• ✅ CI/CD qui bloque si tests échouent

---

Table des matières

1. Pyramide des tests 2. TDD - Test-Driven Development 3. BDD - Behavior-Driven Development 4. Types de tests 5. Bonnes pratiques 6. Anti-patterns 7. Checklist

---

Pyramide des tests

          ┌─────────────┐
          │    E2E      │  ← Peu nombreux (10%)
          │  (UI/API)   │    Lents, fragiles
          ├─────────────┤
          │ Integration │  ← Modérés (20%)
          │   Tests     │    Vérifient les connexions
          ├─────────────┤
          │   Unit      │  ← Nombreux (70%)
          │   Tests     │    Rapides, isolés
          └─────────────┘

Plus on monte, plus c'est lent et coûteux.
Plus on descend, plus c'est rapide et fiable.

Répartition recommandée

---

TDD - Test-Driven Development

Le cycle Red-Green-Refactor

     ┌─────────────────────────────────────┐
     │                                     │
     ▼                                     │
┌─────────┐    ┌─────────┐    ┌──────────┐│
│   RED   │───▶│  GREEN  │───▶│ REFACTOR ││
│  Test   │    │  Code   │    │ Améliorer││
│ échoue  │    │ passe   │    │          ││
└─────────┘    └─────────┘    └──────────┘│
                                   │      │
                                   └──────┘

Étapes

1. RED - Écrire un test qui échoue

• Définir le comportement attendu
• Le test DOIT échouer (sinon il ne teste rien)

2. GREEN - Écrire le minimum de code pour passer

• Code le plus simple possible
• Pas d'optimisation
• Pas de généralisation

3. REFACTOR - Améliorer le code

• Supprimer la duplication
• Améliorer la lisibilité
• Les tests doivent toujours passer

Exemple TDD

// 1. RED - Test qui échoue
test "calculateTotal returns sum of item prices":
  cart = new Cart()
  cart.addItem(Item(price: 10))
  cart.addItem(Item(price: 20))

  assert cart.calculateTotal() == 30
  // ❌ FAIL: method calculateTotal() not defined

// 2. GREEN - Code minimal
class Cart:
  items = []

  addItem(item):
    items.add(item)

  calculateTotal():
    return items.sum(item => item.price)
  // ✅ PASS

// 3. REFACTOR - Améliorer
class Cart:
  items: List<Item> = []

  addItem(item: Item): void
    items.add(item)

  calculateTotal(): Money
    return Money.sum(items.map(i => i.price))
  // ✅ PASS (amélioré avec types)

Règles TDD

1. Un seul test à la fois 2. Le test définit le comportement (pas l'implémentation) 3. Code minimal pour passer 4. Refactor après chaque GREEN 5. Ne jamais ignorer un test qui échoue

---

BDD - Behavior-Driven Development

Format Gherkin

Feature: Shopping Cart
  As a customer
  I want to manage items in my cart
  So that I can purchase them

  Scenario: Add item to cart
    Given I have an empty cart
    When I add a product priced at 29.99€
    Then my cart should contain 1 item
    And the cart total should be 29.99€

  Scenario: Apply discount code
    Given I have a cart with items totaling 100€
    When I apply discount code "SAVE10"
    Then the cart total should be 90€

Structure Given-When-Then

Avantages BDD

• ✅ Documentation vivante
• ✅ Langage commun (dev + métier)
• ✅ Tests lisibles par non-techniciens
• ✅ Focus sur le comportement, pas l'implémentation

---

Types de tests

Tests Unitaires

But: Tester une unité de code en isolation

test "Money can be added":
  a = Money(10, "EUR")
  b = Money(5, "EUR")

  result = a.add(b)

  assert result.amount == 15
  assert result.currency == "EUR"

Caractéristiques:

• ✅ Rapides (< 1s)
• ✅ Isolés (pas de dépendances externes)
• ✅ Déterministes (même résultat à chaque fois)
• ✅ Indépendants (ordre d'exécution n'importe pas)

Tests d'Intégration

But: Tester l'interaction entre composants

test "UserRepository saves and retrieves user":
  repo = UserRepository(database)
  user = User(name: "John")

  repo.save(user)
  retrieved = repo.findByName("John")

  assert retrieved.name == "John"

Caractéristiques:

• ✅ Testent les connexions (DB, API, files)
• ✅ Utilisent de vraies dépendances ou testcontainers
• ✅ Plus lents que unitaires

Tests End-to-End (E2E)

But: Tester le système complet du point de vue utilisateur

test "User can complete purchase":
  browser.goto("/products")
  browser.click("#add-to-cart")
  browser.click("#checkout")
  browser.fill("#email", "test@example.com")
  browser.click("#submit")

  assert browser.text("#confirmation") contains "Order confirmed"

Caractéristiques:

• ✅ Testent le parcours utilisateur complet
• ⚠️ Lents et fragiles
• ⚠️ À utiliser avec parcimonie

Tests de Contrat

But: Vérifier les contrats entre services

test "API returns valid user schema":
  response = api.get("/users/1")

  assert response.status == 200
  assert response.body matches UserSchema

---

Bonnes pratiques

1. Arrange-Act-Assert (AAA)

test "user can change email":
  // Arrange - Préparer
  user = User(email: "old@test.com")

  // Act - Agir
  user.changeEmail("new@test.com")

  // Assert - Vérifier
  assert user.email == "new@test.com"

2. Un assert par test (préférence)

// ❌ Plusieurs assertions non liées
test "user is valid":
  assert user.email is valid
  assert user.password is strong
  assert user.age > 18

// ✅ Tests séparés
test "user email is valid": ...
test "user password is strong": ...
test "user is adult": ...

3. Nommage explicite

// ❌ Noms vagues
test "test1": ...
test "user test": ...
test "it works": ...

// ✅ Noms descriptifs
test "calculateTotal returns zero for empty cart": ...
test "login fails with invalid credentials": ...
test "email is sent after order confirmation": ...

4. Tests indépendants

// ❌ Tests dépendants
test "create user": ...      // Crée user
test "update user": ...      // Utilise user du test précédent
test "delete user": ...      // Utilise user du test précédent

// ✅ Tests indépendants
test "create user":
  user = createUser()
  assert user.exists

test "update user":
  user = createUser()        // Chaque test crée ses données
  user.update(name: "New")
  assert user.name == "New"

5. Utiliser des fixtures/factories

// ❌ Création manuelle répétée
test "test 1":
  user = User(
    name: "John",
    email: "john@test.com",
    password: "hash123",
    role: "admin",
    // ... 10 autres champs
  )

// ✅ Factory
test "test 1":
  user = UserFactory.create(role: "admin")

---

Anti-patterns

1. Tests qui testent l'implémentation

// ❌ Teste HOW (implémentation)
test "save calls repository.insert":
  mock = mock(Repository)
  service.save(user)
  verify mock.insert was called once

// ✅ Teste WHAT (comportement)
test "user is persisted":
  service.save(user)
  assert repository.findById(user.id) exists

2. Tests trop couplés

// ❌ Test qui connaît trop de détails internes
test "process order":
  order.process()
  assert order._internalState == "processed"
  assert order._processedAt != null
  assert order._processorId == 123

// ✅ Test via interface publique
test "process order":
  order.process()
  assert order.isProcessed()

3. Tests flaky (non déterministes)

// ❌ Dépend du temps réel
test "expires after 1 hour":
  item.setExpiry(now + 1.hour)
  sleep(1.hour)              // ❌ Lent et fragile
  assert item.isExpired()

// ✅ Inject time
test "expires after 1 hour":
  clock = FakeClock()
  item.setExpiry(clock.now + 1.hour)
  clock.advance(1.hour)
  assert item.isExpired()

4. Tests commentés

// ❌ JAMAIS
// test "broken test":
//   ...

// ✅ Corriger ou supprimer
// Si temporairement désactivé: skip("reason")

5. Tests sans assertions

// ❌ Ne teste rien
test "create user":
  service.createUser(data)
  // Pas d'assert !

// ✅ Vérifier le résultat
test "create user":
  user = service.createUser(data)
  assert user.id != null
  assert user.email == data.email

---

Checklist

Avant chaque commit

• [ ] Tous les tests passent
• [ ] Nouveaux tests pour nouveau code
• [ ] Couverture ≥ 80%
• [ ] Tests rapides (< 10s total pour unitaires)
• [ ] Pas de tests commentés
• [ ] Noms de tests explicites

Pour chaque nouvelle fonctionnalité

• [ ] Tests unitaires pour la logique métier
• [ ] Tests d'intégration pour les connexions externes
• [ ] Scénarios BDD pour les user stories
• [ ] Tests de edge cases

Pour chaque bug fix

• [ ] Test qui reproduit le bug (échoue avant fix)
• [ ] Fix implémenté
• [ ] Test passe après fix
• [ ] Test de régression ajouté

Métriques

---

Ressources

• Livre: Test-Driven Development - Kent Beck
• Livre: Growing Object-Oriented Software, Guided by Tests - Freeman & Pryce
• Livre: The Art of Unit Testing - Roy Osherove
• Article: Testing Trophy

---

Date de dernière mise à jour: 2025-01 Version: 1.0.0 Auteur: The Bearded CTO