Réponse.

L'automatisation des scénarios négatifs est une partie intégrante d'un système de test complet. Ce sont des vérifications qui valident la robustesse du système face à des actions erronées, des données incorrectes, des pannes de services et d'autres situations anormales.

Historique de la question :

Auparavant, l'accent était principalement mis sur les scénarios positifs (happy paths), car ceux-ci sont plus faciles à automatiser et à maintenir. Cependant, les exigences de qualité ont augmenté, et de plus en plus de bugs apparaissent précisément aux limites, avec des conditions erronées ou peu évidentes. Leur test manuel devient rapidement obsolète, et l'automatisation permet de suivre les dégradations.

Problème :

Définir et couvrir tous les scénarios négatifs possibles
Vérifier correctement les messages d'erreur, la validité de l'état du système après un échec de l'opération
Maintenir les tests lors des modifications de la logique métier

Solution :

Identification des scénarios négatifs et leur systématisation (Boundary Value Analysis, Equivalence Partitioning)
Utilisation d'asserts et de validateurs personnalisés pour vérifier les messages d'erreur, les codes HTTP, les exceptions
"Nettoyage" automatique de l'état du système après un test négatif

Caractéristiques clés :

Énoncé explicite des tests pour les erreurs, exceptions, entrées non standards
Vérification du message d'erreur et de l'état interne du système
Contrôle des effets secondaires : après un test négatif, le système doit rester dans un état cohérent

Questions pièges.

Est-il suffisant de vérifier seulement quelles erreurs sont renvoyées lors des tests négatifs ?

Non. Il est important de vérifier non seulement le contenu de l'erreur, mais aussi qu'après l'erreur, aucun changement d'état du système ne s'est produit (par exemple, qu'aucune entrée incorrecte n'a été ajoutée dans la base de données).

Faut-il automatiser tous les scénarios négatifs possibles ?

Non. Il peut y en avoir un nombre infini ; il faut se concentrer sur les plus probables et critiques (Boundary Value, Null/Empty, type incorrect, injections SQL, etc.), et les autres au fur et à mesure des bugs signalés.

Peut-on utiliser le même traitement pour tous les cas négatifs ?

Non. Différents scénarios négatifs nécessitent des vérifications, un traitement des exceptions et des rollbacks différents ; des asserts génériques ne suffisent pas.

Erreurs typiques et anti-patterns

Ignorer les scénarios négatifs ou les couvrir "pour la forme"
Vérification peu convaincante de l'erreur (par exemple, seulement le code 500, sans vérification du texte ou effet secondaire)
Environnement de test non nettoyé après l'échec d'un test

Exemple de la vie réelle

Cas négatif

Le système teste uniquement des scénarios d'inscription valides. L'inscription avec un email vide n'est pas testée de manière automatisée. En conséquence, le problème qu'il est possible d'inscrire un utilisateur avec une adresse e-mail vide n'est découvert qu'en production.

Avantages :

Facilité de maintenance des tests
Peu de tests automatisés et exécution rapide

Inconvénients :

Des bugs critiques passent en production
Augmentation des coûts de correction et de rollback

Cas positif

Pour chaque scénario négatif (absence d'email, format incorrect, injection SQL), il existe un test automatisé qui vérifie explicitement l'absence de nouveau compte et le contenu du message d'erreur.