Parlant au quotidien, en termes pratiques, je pense que cela dépend totalement du contexte .
Dans une équipe de taille moyenne, travaillant selon des normes élevées / très élevées (pensez aux systèmes bancaires, militaires, à grande échelle, à budget élevé ou aux systèmes critiques), je pense clairement que le "débogage" devrait être "le résultat de tests" , et ils sont clairement des choses très différentes . Idéalement, les tests mènent au débogage (dans un environnement intermédiaire) et en production, nous avons besoin de près de zéro.
Les tests sont de grande envergure, réguliers et très formalisés - tandis que le débogage est un processus particulier qui se produit occasionnellement lorsqu'il est nécessaire de corriger une défaillance particulière - ce qui n'est pas évident et nécessite une enquête plus approfondie sur le fonctionnement d'un système et les sorties résultantes.
Ici, dans mon esprit, le test est quelque chose d'essentiel, tandis que le débogage est un outil spécifique nécessaire uniquement lorsque la résolution d'un échec est opaque.
Je comprends parfaitement l' utilité évidente de TDD pour les grandes équipes et / ou les systèmes qui ne peuvent tout simplement pas se permettre d'être "buggy". Il est également clair que cela a beaucoup de sens pour les systèmes complexes (souvent "dorsaux") ou s'il y a une proportion élevée de complexité dans le code par rapport à la sortie. Le «test» a alors une chance réaliste d'informer quand et pourquoi les échecs se produisent. Les systèmes qui effectuent beaucoup de travaux complexes et / ou produisent des résultats clairement mesurables sont généralement facilement testables, et les tests sont donc distincts du débogage. Dans ces cas, les tests impliquent fortement une méthode formalisée, basée sur la procédure, pour confirmer ou dé-confirmer la correspondance des attentes et des résultats réels. Les tests ont lieu tout le temps et nous informent parfois de la nécessité d'un débogage.
Ce serait bien si c'était une vérité omniprésente, j'adorerais que mes cycles de développement soient délimités par une sortie binaire clairement définie (rouge, verte) mais ...
Dans mon cas (ce qui est certes particulier - travailler à 98% en solo sur des systèmes d'administration d'entreprise basés sur le Web de petite à moyenne taille, sous-financés), je ne vois vraiment pas comment TDD pourrait m'aider. Ou plutôt «débogage» et «test» sont pratiquement les mêmes.
Principalement, si l'utilisation du terme "test" implique / est étroitement liée à la méthodologie de TDD.
Je sais que c'est une chose totalement, totalement anti -Zeitgeist "fuyez le non-croyant, fuyez, fuyez", chose horriblement moche à dire. Mais en pensant à mon contexte, avec un chapeau pratique, je ne le fais même pas vaguement, dans mon imagination la plus folle, je vois comment TDD pourrait m'aider à offrir un meilleur rapport qualité-prix à mes clients.
Ou plutôt, je suis fortement en désaccord avec l'hypothèse courante selon laquelle "tester" est un processus formel basé sur du code.
Mon objection fondamentale (applicable dans mon particulier contexte *) est que ...
Si je ne peux pas écrire du code qui fonctionne de manière fiable - alors comment diable suis-je censé écrire du code qui fonctionne de manière fiable pour tester ledit code vraisemblablement sous-standard.
Pour moi, je n'ai jamais vu d'exemple ni d'argument qui (dans mon contexte particulier) m'ait suffisamment enthousiasmé pour même prendre la peine de penser à écrire un seul test , je pourrais écrire un code de test ridiculement insignifiant en ce moment, peut-être "mon référentiel renvoie-t-il un utilisateur entité avec Nom == X, quand je lui demande exactement - et seulement - cela? ", mais il y a probablement plus d'utilité en moi à écrire ce streaming, peut-être-l'Internet-vraiment-est-juste-pur-idiot-jaillissant- auto-gratifiant-follement sous-informé-sang-bouillant-ignorant-gaspillage-idiot, mais je ressens juste le besoin de jouer l'avocat du diable ici. (J'espère que quelqu'un va me montrer la lumière et me convertir, peut-être que cela finira par donner à mes clients un meilleur rapport qualité-prix?).
On peut dire que le «débogage» est parfois le même que le «test». Par cela, je veux vraiment dire que dans ma vie professionnelle quotidienne, je passe au moins un tiers de mon temps à jouer avec la version locale de mon système dans différents navigateurs, essayant désespérément diverses choses loufoques différentes pour tenter de casser mon travail, puis enquêter sur les raisons pour lesquelles il a échoué et les corriger.
Je suis à 100% d'accord avec l'utilité évidente du mantra TDD "rouge / vert / refactor", mais pour moi (travaillant avec un petit budget med, solo dev RIA land), j'aimerais vraiment que quelqu'un me montre comment je pourrais peut - être , logiquement et de façon réaliste, obtenir une valeur supplémentaire en écrivant plus ( tout comme un code de test potentiellement défectueux ) que je ne le fais en interagissant avec la sortie complète (et essentiellement uniquement) de mes efforts qui sont essentiellement liés à une interaction humaine réelle.
Pour moi, lorsque les développeurs parlent de "tests", cela implique généralement TDD.
J'essaie de coder comme s'il y avait des tests, je pense que tous les modèles / pratiques et tendances que tout ce développement axé sur les tests a encouragés sont fantastiques et beaux, mais pour moi dans mon petit monde, "tester" n'écrit pas plus de code, c'est en fait tester le monde réel le produit de manière réaliste, et c'est pratiquement la même chose que le débogage, ou plutôt le changement actif ici est le "débogage" qui est le résultat direct de "tests" non automatisés centrés sur la sortie humaine. Cela contraste avec la conception généralement acceptée du «test» comme quelque chose d'automatisé et de formel, et du «débogage» comme quelque chose d'humain et ad hoc ou non structuré.
Si l'objectif est vraiment le rapport qualité / prix et l'effort, et que vous créez des applications interactives basées sur le Web, alors la sortie de l'effort est les pages Web et très essentiellement comment elles réagissent aux entrées humaines - donc "tester" est mieux réalisé en testant ces pages Web, grâce à une véritable interaction humaine. Lorsque cette interaction conduit à des sorties inattendues ou indésirables, le "débogage" se produit. Le débogage est également étroitement lié à l'idée d'une inspection en temps réel de l'état du programme. Les tests sont généralement associés à l'automatisation qui, je pense, est souvent une association malheureuse.
Si l'objectif est vraiment la valeur de l'effort et que les tests automatisés sont efficaces et très bénéfiques, alors que le débogage n'est qu'un résultat de ces tests ou un mauvais substitut aux tests automatisés, alors pourquoi est le deuxième site Web le plus visité au monde (Facebook ) si souvent criblé de bugs aveuglément évidents (pour les utilisateurs, mais clairement pas pour l'équipe de test et le code de test)?
Peut-être que c'est parce qu'ils se concentrent sur les feux verts rassurants et oublient d'utiliser réellement les sorties de leur travail?
Trop de développeurs pensent-ils que le test est quelque chose que vous faites avec du code, et que le débogage est quelque chose que vous faites occasionnellement avec l'IDE parce qu'une icône devient rouge et vous ne pouvez pas comprendre pourquoi? Je pense que ces mots ont des jugements de valeur malheureux qui leur sont associés, qui obscurcissent généralement la réalité pratique de ce sur quoi nous devrions nous concentrer pour combler les écarts entre les attentes et les résultats.