Pourquoi dit-on souvent que les cas de test doivent être créés avant de commencer le codage?

Question

Pourquoi dit-on souvent que les cas de test doivent être créés avant de commencer le codage?
Quels sont ses avantages et ses inconvénients si nous n'écoutons pas ces conseils?

De plus, ces conseils se réfèrent-ils aux tests de la boîte noire, aux tests de la boîte blanche ou aux deux?

tdammers · Accepted Answer

L'écriture de tests avant les implémentations est l'une des idées fondamentales derrière le développement piloté par les tests (TDD). La procédure est la suivante:

écrire un test qui échoue
changer le code pour le faire passer, sans casser aucun autre test
refactoriser le code, vérifier que tous les tests réussissent encore

Cette procédure est la même si vous implémentez une fonctionnalité ou corrigez un bogue; il est souvent appelé "Red-Green-Refactor" (rouge = échec du test, vert = réussite du test). Les avantages de cette méthode sont nombreux:

le test définit clairement ce qui constitue un "fait"
le test documente comment vous prévoyez d'utiliser le code
si vous le faites correctement, vous créez une suite de tests complète avec une couverture à 100% comme sous-produit de votre processus de développement, ce qui signifie que vous avez toujours des tests de régression fiables à portée de main, quoi que vous fassiez
le codage pour répondre à un cas de test (et rien d'autre) vous aide à rester concentré sur une tâche et empêche le fluage des fonctionnalités
le cycle red-green-refactor crée un historique de validation agréable, propre et traçable et correspond bien à une approche de référentiel de branche de fonctionnalité (chaque branche de fonctionnalité commence par une validation qui ajoute un test d'échec, puis une ou plusieurs validations jusqu'à ce que "vert" soit atteint , puis un ou plusieurs refactoring commits).
vous produisez des versions de travail à intervalles réguliers - idéalement, chaque cycle de refactorisation rouge-vert se termine par un produit potentiellement livrable, mais à tout le moins, il devrait se construire sans échecs et passer tous les tests.

Maintenant pour les inconvénients:

Tout le code ne se prête pas aux tests automatisés. Cela peut être dû au fait que c'est une base de code héritée écrite sans tests automatisés à l'esprit; cela peut être dû au fait que le domaine problématique est tel que certaines choses ne peuvent être moquées; ou peut-être vous reposez-vous sur des sources de données externes qui ne sont pas sous votre contrôle et seraient trop compliquées à railler; etc.
Parfois, l'exactitude, la maintenabilité et la stabilité ne sont pas suffisamment élevées sur la liste des priorités. Cela semble mauvais, mais cela ne doit pas être: si vous écrivez un script à usage unique pour convertir par lots un tas de documents, l'écriture de tests est stupide - vous l'exécutez simplement sur quelques documents de test, résultat, et c'est tout. Les tests automatisés n'ajouteraient aucune valeur ici.
Écrire le test avant d'écrire le code implique que vous savez déjà exactement ce que vous voulez faire. Très souvent, cependant, vous ne le faites pas, et une quantité importante de programmation exploratoire est nécessaire pour avoir une idée du domaine de problème particulier; et le plus souvent, les résultats d'un tel codage exploratoire sont ensuite mis en forme pour devenir le véritable produit. Les tests automatisés sont tout aussi précieux pour de tels produits, mais cela n'a pas beaucoup de sens de les ajouter avant de savoir ce que vous allez faire. Dans ce cas, il est préférable de prendre le prototype à la fin de la phase exploratoire, d'ajouter des tests pour couvrir tout ce que vous avez jusqu'à présent et de passer à red-green-refactor à partir de là.
Le test avant la mise en œuvre n'est pas la tasse de thé de tout le monde; écrire l'implémentation semble d'abord plus naturel, et certaines personnes ont plus de facilité à entrer dans un flux de cette façon

Michael Borgwardt · Answer

Pourquoi dit-on souvent que les cas de test doivent être créés avant de commencer le codage?

C'est un principe de base de développement piloté par les tests , mais pas une "meilleure pratique" générale. Tout le monde ne veut ni n'a besoin de faire du TDD, même si ses partisans affirment souvent que tout le monde en bénéficierait.

Quels sont ses avantages et ses inconvénients si nous n'écoutons pas ces conseils?

L'avantage est qu'il vous oblige à penser à votre code dans une perspective de test avant de l'écrire, ce qui présente deux avantages principaux: vous êtes moins susceptible d'oublier les cas spéciaux et les conditions aux limites, et votre code doit être testable et donc modulaire. Autre avantage important: à tout moment, vous savez que votre code fonctionne comme vous le pensiez.

L'inconvénient est qu'il peut encourager la réflexion sur les détails de bas niveau et ignorer les problèmes de conception importants (mais la même chose peut se produire si vous commencez simplement à coder). De plus, la conception la plus facilement testable n'est pas nécessairement la meilleure (mais probablement bien meilleure qu'une conception issue d'un codage ad hoc).

Bien sûr, il y a la question de savoir si TDD permet de gagner plus de temps que d'écrire tous ces coûts de tests unitaires. Ses partisans l'affirment certainement.

De plus, ces conseils se réfèrent-ils aux tests de la boîte noire, aux tests de la boîte blanche ou aux deux?

En général, TDD traite exclusivement des tests unitaires , qui sont des tests en boîte blanche. Les tests d'intégration doivent être effectués en plus.

gnat · Answer

Quand j'écris test d'abord , il ne s'agit pas vraiment de vérifier le bon fonctionnement de mon code, pas vraiment de boîte noire ou boîte blanche ou tout ce qui concerne assurance qualité , et voici pourquoi ...

Au fil des ans, j'ai pratiqué et perfectionné une compétence pour convaincre la direction que j'ai besoin de bons testeurs ^{1 , 2 ,} et cela suffit pour que mon code fonctionne comme prévu sans que j'y réfléchisse beaucoup.

La raison principale pour laquelle je préfère le test est qu'il m'aide à comprendre comment concevoir mon code afin qu'il soit pratique à utiliser. Je ne suis pas bon à imaginer dans ma tête comment mon module sera utilisé par d'autres modules, donc je peux le faire trop compliqué et cela me mordra plus tard et nécessitera peut-être même une refonte.

C'est un problème que je code un module pour moi-même ou pour quelqu'un d'autre, il est tout aussi pénible d'utiliser moi-même une interface peu pratique et d'avoir à expliquer son utilisation à d'autres programmeurs.

L'approche "test d'abord" me sauve de cette douleur; il ne nécessite pas d'imagination pour voir immédiatement comment mon module sera utilisé s'il est conçu de telle ou telle manière et permet de choisir facilement le plus pratique.

Lors du codage d'un module pour quelqu'un d'autre, cela m'évite également d'avoir à expliquer péniblement comment l'utiliser.

^{Regardez, codez dans this test montre comment utiliser ce module et si vous l'exécutez, vous verrez également les résultats auxquels vous devez vous attendre. Utilisation d'une autre manière que celle indiquée dans this test serait une erreur. Maintenant, pars et laisse-moi faire quelque chose d'intéressant.}

Oded · Answer

Il est dit dans le contexte de la pratique TDD / BDD , qui sont concevoir des méthodologies, pas des méthodologies de test.

Avec TDD/BDD, l'idée est de chasser l'utilisation de l'API avant d'écrire l'API, de la faire évoluer avec des tests.

Vu sous cet angle, il s'agit d'écrire un test pour un appel d'API inexistant ou un test pour un comportement d'API inexistant, puis de l'implémenter.

Quant aux tests de blackbox/whitebox - encore une fois, il ne s'agit pas de tester - il s'agit de design .

dietbuddha · Answer

Pourquoi dit-on souvent que les cas de test doivent être créés avant de commencer le codage?

Il y a plusieurs raisons pour lesquelles cela est dit.

Certaines personnes abordent les tests (boîte noire) comme des contrats. Cela oblige la personne qui écrit le test et la personne qui met en œuvre le code à avoir un ensemble clair de critères de réussite. Cela signifie que vous écrivez du code pour respecter le contrat et c'est ainsi que vous savez quand la fonctionnalité requise est remplie.
TDD (Test Driven Development) est une pratique où vous pilotez tout le développement à travers des tests. Classiquement, cela se fait avec des tests unitaires, mais plus récemment avec des tests à tout niveau appropriés à votre produit et à votre processus.

Quels sont ses avantages et ses inconvénients si nous n'écoutons pas ces conseils?

Avantages

Élimine l'ambiguïté plus tôt dans le processus, car vous devez comprendre quels sont les critères de réussite avant d'écrire le test.
Certains partisans suggèrent qu'il existe des avantages de conception spécifiques à l'unité TDD, car elle impose un couplage lâche et une conception plus modulaire.
Confiance que votre code fonctionne (au moins pour les portions testées).

Contre

Comprendre comment écrire des tests maintenables.
Comprendre comment écrire de bons tests.
Comprendre quand faire le compromis entre un bon test très cher et un test moins bon moins cher.
Plus de code à maintenir

De plus, ces conseils se réfèrent-ils aux tests de la boîte noire, aux tests de la boîte blanche ou aux deux?

Ça dépend. La plupart des tests unitaires ont tendance à être plus blackbox dans la mesure où ils examineront les entrées et sorties de la méthode ou de la fonction. Cependant, il y a des moments où des simulations ou des talons sont nécessaires, ce qui en fait davantage un test de boîte blanche car il nécessite désormais des informations sur la mise en œuvre. Il peut s'agir d'un point discutable aux fins de TDD car le développeur est généralement celui qui écrit les tests.