La pyramide des tests & les quadrants — quoi automatiser en premier

L'idée, en une ligne

Attrapez chaque bug à l'endroit le moins cher qui peut l'attraper. Voilà toute la règle. L'image qui l'explique a un vrai nom que les examinateurs utilisent — la pyramide des tests — donc ça vaut la peine de le connaître.

Pourquoi cette forme ?

La forme est en réalité une question de coût. Voici ce que chaque couche vous coûte :

• Les tests unitaires s'exécutent en millisecondes, pointent droit sur la fonction cassée, et donnent rarement de fausses alertes.
• Les tests de bout en bout sont lents, cassent facilement, et quand ils échouent ils vous disent seulement que quelque chose s'est cassé quelque part.
• Donc vous écrivez beaucoup des moins chers et très peu des plus chers.

Voyez-le à l'œuvre

Une suite de tests saine reflète la pyramide : beaucoup d'unitaires, quelques-uns de service, peu de bout en bout. Voici un moyen rapide de vérifier l'équilibre.

# Count of tests at each layer
suite = {"unit": 420, "service": 60, "e2e": 12}

total = sum(suite.values())
unit_share = suite["unit"] / total
print(f"unit share: {unit_share:.0%}")   # unit share: 85%

# Warning sign: if e2e outnumbers unit, the pyramid is upside down
assert suite["unit"] > suite["e2e"], "top-heavy: push tests down"

# Same bug, cheapest layer that catches it wins:
catches = {"discount math": "unit", "api contract": "service", "checkout flow": "e2e"}
for bug, layer in catches.items():
    print(f"{bug:14} -> test at: {layer}")

Lisez-le de haut en bas : vous avez compté vos tests, vérifié que la forme n'était pas à l'envers, puis associé chaque genre de bug à la couche la moins chère qui peut l'attraper.

Avancé — le piège et la carte plus large

L'erreur classique est le cône de glace : une grosse couche de tests d'écran en équilibre sur presque aucun test unitaire. Ça semble complet, mais c'est lent et instable — et c'est exactement la forme qu'un testeur manuel construit par défaut. Si votre couche du haut est plus grande que celle du bas, c'est l'avertissement.

Il existe aussi une carte compagne appelée les quadrants de test. Elle trie les vérifications selon deux questions : cette vérification aide-t-elle l'équipe à construire ou critique-t-elle le produit fini, et est-elle technique ou orientée métier ? Sa leçon principale : tout n'appartient pas à l'automatisation — certaines vérifications se font encore par un humain.

Basé sur « The Practical Test Pyramid » de Martin Fowler (martinfowler.com)