Unit Test Generator

Unit Test Generator

Workflow

Étape 1 — Analyser le code à tester

• Identifier toutes les méthodes/fonctions publiques (l'interface contractuelle).
• Cartographier les dépendances injectées (constructeur, DI, imports).
• Repérer les side effects : I/O, DB, HTTP, mutation d'état global, horloge.
• Détecter les branches conditionnelles (if/else, switch, early return, ternaire) — chaque branche = un cas de test distinct.

Étape 2 — Choisir le bon framework

Critère de décision : si le projet a déjà un framework installé, l'utiliser ; si greenfield, préférer Vitest (TS), pytest (Python), xUnit (C#), JUnit 5 (Java).

Étape 3 — Identifier tous les cas de test

Pour chaque méthode publique, couvrir systématiquement :

1. Happy path — entrée valide, résultat nominal.
2. Edge cases — null, undefined, chaîne vide, liste vide, zéro, négatif, max value.
3. Error cases — exception attendue, code d'erreur métier, état invalide.
4. Interactions — appels aux dépendances (mock appelé N fois avec tels args).

Étape 4 — Mocker les dépendances

Principe : isoler la SUT (System Under Test) de tout ce qui n'est pas elle.

# Python — pytest-mock
def test_get_user_returns_none_when_not_found(mocker):
    repo = mocker.MagicMock()
    repo.find_by_id.return_value = None
    svc = UserService(repo)
    assert svc.get_user(99) is None
    repo.find_by_id.assert_called_once_with(99)

// C# — Moq + FluentAssertions
[Fact]
public void GetUser_ShouldReturnNull_WhenNotFound()
{
    var repo = new Mock<IUserRepository>();
    repo.Setup(r => r.FindById(99)).Returns((User?)null);
    var svc = new UserService(repo.Object);

    var result = svc.GetUser(99);

    result.Should().BeNull();
    repo.Verify(r => r.FindById(99), Times.Once);
}

// TypeScript — Vitest
import { vi, describe, it, expect } from 'vitest';
import { UserService } from './UserService';

describe('UserService.getUser', () => {
  it('returns null when user not found', async () => {
    const repo = { findById: vi.fn().mockResolvedValue(null) };
    const svc = new UserService(repo as any);
    expect(await svc.getUser(99)).toBeNull();
    expect(repo.findById).toHaveBeenCalledWith(99);
  });
});

Étape 5 — Écrire avec le pattern AAA

Arrange → Act → Assert  (une seule assertion logique par test)

Nommage : Should_<résultat>_When_<condition> ou <méthode>_<état>_<attendu>.

Étape 6 — Tests paramétrés pour les variations de données

# pytest
@pytest.mark.parametrize("amount,expected", [
    (0,     False),
    (-1,    False),
    (0.01,  True),
    (10_000, True),
])
def test_is_valid_amount(amount, expected):
    assert is_valid_amount(amount) == expected

// xUnit
[Theory]
[InlineData(0,      false)]
[InlineData(-1,     false)]
[InlineData(0.01,   true)]
[InlineData(10_000, true)]
public void IsValidAmount_ShouldMatchExpected(decimal amount, bool expected)
    => Assert.Equal(expected, PaymentValidator.IsValidAmount(amount));

// Vitest / Jest
it.each([
  [0,      false],
  [-1,     false],
  [0.01,   true],
  [10_000, true],
])('isValidAmount(%s) → %s', (amount, expected) => {
  expect(isValidAmount(amount)).toBe(expected);
});

Étape 7 — Vérifier la couverture

# Python
pytest --cov=src --cov-report=term-missing --cov-fail-under=80

# TypeScript (Vitest)
vitest run --coverage          # génère coverage/index.html

# .NET
dotnet test --collect:"XPlat Code Coverage"
reportgenerator -reports:coverage.cobertura.xml -targetdir:coverageReport

# Java (Maven + JaCoCo)
mvn test jacoco:report          # target/site/jacoco/index.html

Objectif minimal : 80 % lignes + 70 % branches sur le code métier. Ne pas poursuivre la couverture sur les DTOs, générés, migrations.

Étape 8 — Refactoring des tests

• Partager l'initialisation via beforeEach / fixture / builder factory — pas de copier-coller.
• Créer des TestBuilders (pattern Builder) pour les entités complexes.
• Regrouper par classe/feature dans des describe / TestClass / inner classes.
• Supprimer les tests qui vérifient un détail d'implémentation (ex : ordre exact des appels internes).

Garde-fous — anti-patterns à éviter

Bonnes pratiques 2026

• Test Doubles hiérarchie : préférer les Fake (implémentation légère en mémoire) aux Mock quand la logique est non triviale.
• Snapshot testing avec jest-snapshot / Verify (.NET) pour les sorties complexes (JSON, HTML, rapports) — évite les assertions fragiles ligne à ligne.
• Contract testing (Pact) pour les intégrations HTTP entre services : ne pas mocker le contrat, le valider.
• Mutation testing (Stryker .NET/JS, mutmut Python) : mesure la qualité réelle des assertions, pas juste la couverture de lignes.
• Tests de propriétés (Hypothesis Python, fast-check JS, FsCheck .NET) pour explorer l'espace des entrées au-delà des cas manuels.
• Placer les tests au plus proche du code : src/services/user.service.spec.ts ou tests/ miroir de src/ selon la convention du projet.
• Faire tourner les tests en mode watch pendant le développement (vitest, pytest-watch, dotnet watch test).