Accueil › Glossaire › Unit Test

Unit Test (Test Unitaire) et Intelligence Artificielle

Un unit test (test unitaire) est un test automatisé qui vérifie le comportement d’une unité isolée de code (une fonction, une méthode, une classe) en l’exécutant avec des entrées connues et en vérifiant que la sortie correspond à l’attendu. La génération de tests unitaires par LLM automatise la création de ces tests à partir du code source, en couvrant les cas normaux, les cas limites et les cas d’erreur.

Définition et principes

Le test unitaire est la brique de base de la pyramide de tests. Il vérifie qu’une unité de code (typiquement une fonction ou une méthode) produit le bon résultat pour une entrée donnée, en isolation du reste du système. Les dépendances externes (base de données, API, système de fichiers) sont remplacées par des mocks ou des stubs.

Un bon test unitaire suit le pattern AAA :

Le problème : malgré son importance universellement reconnue, le test unitaire est souvent négligé. Les développeurs le perçoivent comme fastidieux et ne produisant pas de fonctionnalité visible. La recherche confirme que les sujets liés à la génération de tests sont sous-représentés dans la littérature par rapport à la génération de code. C’est précisément ce qui fait de la génération automatique de tests unitaires l’un des cas d’usage IA les plus impactants.

Génération automatique de tests unitaires par LLM

Approche directe : LLM dans l’IDE

La méthode la plus simple : sélectionnez une fonction dans votre IDE (Cursor, Copilot), et demandez « Génère des tests unitaires pour cette fonction ». Le LLM analyse la signature, le corps de la fonction et les types pour produire une suite de tests couvrant les cas normaux, les cas limites (listes vides, valeurs nulles, types inattendus) et les cas d’erreur.

# Fonction à tester
def calculate_discount(price: float, tier: str) -> float:
    """Applique une réduction selon le tier client."""
    if tier == "gold":
        return price * 0.8
    elif tier == "silver":
        return price * 0.9
    return price

# Tests générés par LLM (pytest)
import pytest

def test_gold_discount():
    assert calculate_discount(100.0, "gold") == 80.0

def test_silver_discount():
    assert calculate_discount(100.0, "silver") == 90.0

def test_no_discount():
    assert calculate_discount(100.0, "bronze") == 100.0

def test_zero_price():
    assert calculate_discount(0.0, "gold") == 0.0

def test_negative_price():
    result = calculate_discount(-50.0, "gold")
    assert result == -40.0  # Comportement actuel, possiblement un bug

def test_none_tier():
    # Vérifie le comportement avec un tier inattendu
    assert calculate_discount(100.0, None) == 100.0

Notez que le LLM a identifié un cas potentiellement problématique (prix négatif) et l’a documenté avec un commentaire. C’est la valeur ajoutée de la génération IA par rapport à l’écriture manuelle : le modèle explore systématiquement les cas limites que le développeur pourrait oublier.

Approche itérative : Cover-Agent et CoverUp

Les outils de deuxième génération vont plus loin que la simple génération. Ils opèrent dans une boucle itérative qui maximise la couverture de code :

Cover-Agent (Qodo, anciennement CodiumAI), inspiré du papier TestGen-LLM de Meta, implémente exactement cette boucle. Vous fournissez le fichier source, le fichier de tests, le rapport de couverture, et la couverture cible. L’agent itère automatiquement jusqu’à atteindre l’objectif :

cover-agent 
  --source-file-path "calculator.py" 
  --test-file-path "test_calculator.py" 
  --code-coverage-report-path "./coverage.xml" 
  --test-command "pytest --cov=. --cov-report=xml" 
  --coverage-type "cobertura" 
  --desired-coverage 90 
  --max-iterations 10

CoverUp (recherche ACM 2024) combine analyse de couverture, contexte de code et feedback itératif pour guider le LLM. Il atteint une couverture médiane ligne+branche de 80 % (contre 47 % pour CodaMosa, un générateur hybride recherche/LLM). Sur certains benchmarks, CoverUp atteint 89 % de couverture globale.

Tests unitaires pour les applications LLM

Le concept de « test unitaire » s’étend aux applications basées sur des LLM. Le framework DeepEval adapte le pattern AAA aux sorties non déterministes des LLM :

import pytest
from deepeval import assert_test
from deepeval.metrics import GEval
from deepeval.test_case import LLMTestCase, LLMTestCaseParams

def test_chatbot_correctness():
    correctness = GEval(
        name="Correctness",
        criteria="La réponse est-elle factuellement correcte "
                 "par rapport à la réponse attendue ?",
        evaluation_params=[
            LLMTestCaseParams.ACTUAL_OUTPUT,
            LLMTestCaseParams.EXPECTED_OUTPUT
        ],
        threshold=0.5
    )

    test_case = LLMTestCase(
        input="Quel est le prix de Claude Pro ?",
        actual_output="Claude Pro coûte 20 $/mois.",
        expected_output="L'abonnement Claude Pro est à 20 $/mois.",
        retrieval_context=[
            "Claude Pro : 20 $/mois, accès complet."
        ]
    )

    assert_test(test_case, [correctness])

La différence clé : au lieu de assert result == expected, le scoring utilise un LLM-as-a-Judge qui compare la sortie réelle à la sortie attendue de manière sémantique (pas par exact match). Cela permet de tester des applications LLM malgré leur non-déterminisme.

DeepEval s’intègre nativement avec pytest et peut être exécuté dans un pipeline CI/CD pour des tests de régression automatisés sur chaque changement de prompt ou de modèle.

Couverture de code et métriques

La couverture de code (code coverage) mesure la proportion du code source exécutée pendant les tests. C’est la métrique principale pour évaluer la qualité d’une suite de tests unitaires.

La couverture de mutations est particulièrement pertinente pour évaluer les tests générés par IA. Un test peut couvrir une ligne sans réellement vérifier son comportement (assertion trop laxiste). Le mutation testing modifie le code source (par exemple, remplace > par >=) et vérifie que les tests détectent la modification. Un test qui ne détecte pas la mutation est un « test fantôme » qui donne un faux sentiment de sécurité.

Bonnes pratiques pour les tests unitaires IA

1. Commencez avec un fichier squelette. Fournissez au LLM (ou à Cover-Agent) un fichier de test existant avec au moins un test et les imports nécessaires. Le modèle s’aligne sur le style et les conventions existants.

2. Spécifiez les cas limites. Le prompt « Génère des tests » produit des tests basiques. Le prompt « Génère des tests couvrant les cas normaux, les listes vides, les valeurs None, les entrées négatives, les types incorrects et les exceptions attendues » produit une suite bien plus robuste.

3. Validez les assertions, pas juste l’exécution. Le piège classique du test IA : le test s’exécute sans erreur mais n’assert rien de significatif. Reviewez spécifiquement les assertions pour vérifier qu’elles testent le bon comportement, pas juste l’absence d’exception.

4. Utilisez la boucle couverture → génération. Exécutez Coverage.py, identifiez les lignes non couvertes, demandez au LLM de générer des tests ciblés pour ces lignes. C’est plus efficace que de demander des tests « en général ». Cover-Agent automatise cette boucle.

5. Mockez les dépendances externes. Pour les tests unitaires d’applications LLM ou d’agents IA, mockez la couche non déterministe (l’appel au LLM) et testez le code déterministe autour (routing, extraction d’arguments, gestion des résultats). Le principe : tester tout sauf le LLM lui-même.

6. Nommez les tests de manière descriptive. test_calculate_discount_gold_tier_applies_20_percent est plus utile que test_1. Quand un test échoue, le nom doit suffire à comprendre ce qui a cassé. Demandez explicitement au LLM de nommer les tests de manière descriptive.

7. Utilisez la température 0. Pour la génération de tests, fixez la température à 0 (ou très basse). Les tests doivent être reproductibles et déterministes. La créativité est une qualité pour la fiction, pas pour les tests.

Outils pour la génération de tests unitaires

Unit test vs. integration test

Les deux sont complémentaires et nécessaires. Les tests unitaires forment la base de la pyramide (nombreux, rapides, ciblés). Les tests d’intégration vérifient que les pièces s’assemblent correctement. L’IA excelle dans la génération de tests unitaires (tâche locale et bien définie) et progresse dans les tests d’intégration (qui nécessitent une compréhension plus globale du système).

Verdict

La génération automatique de tests unitaires est l’un des cas d’usage IA les plus matures et les plus immédiatement productifs. Les outils actuels (Cover-Agent, CoverUp, Copilot, Claude Code) peuvent atteindre 80 à 90 % de couverture de manière automatisée, un niveau qui aurait nécessité des heures de travail manuel.

Notre recommandation : utilisez Copilot ou Cursor pour la génération de tests en contexte dans l’IDE (le plus rapide à démarrer). Pour maximiser la couverture de manière systématique, Cover-Agent est l’outil de référence. Pour les applications LLM, DeepEval adapte le concept de test unitaire aux sorties non déterministes. Et dans tous les cas, reviewez les assertions des tests générés : un test qui passe mais ne vérifie rien est pire qu’un test absent, car il donne un faux sentiment de sécurité.