Wenn ich alltäglich und praktisch spreche, denke ich, dass es völlig vom Kontext abhängt .
In einem mittelgroßen Team, das nach hohen / sehr hohen Standards arbeitet (denken Sie an Bank-, Militär-, Groß-, Hochbudget- oder geschäftskritische Systeme), sollte "Debuggen" eindeutig "ein Ergebnis von Tests" sein , und das sind sie eindeutig ganz andere Dinge . Im Idealfall führt das Testen zum Debuggen (in einer Staging-Umgebung), und in der Produktion benötigen wir nahezu Null von beiden.
Das Testen ist umfangreich, regelmäßig und sehr formalisiert - während das Debuggen ein besonderer Prozess ist, der gelegentlich auftritt, wenn ein bestimmter Fehler behoben werden muss -, was nicht offensichtlich ist und eine eingehendere Untersuchung der Funktionsweise und der daraus resultierenden Ergebnisse eines Systems erfordert.
In meinen Augen ist das Testen etwas Wesentliches, während das Debuggen ein spezielles Werkzeug ist, das nur benötigt wird, wenn die Lösung eines Fehlers undurchsichtig ist.
Ich verstehe den offensichtlichen Nutzen von TDD für große Teams und / oder Systeme, die es sich einfach nicht leisten können, "fehlerhaft" zu sein. Dies ist auch für komplexe (häufig "Back-End") Systeme sehr sinnvoll oder wenn der Code im Vergleich zur Ausgabe einen hohen Anteil an Komplexität aufweist. Dann hat "Testen" eine realistische Chance zu informieren, wann und warum Fehler auftreten. Systeme, die viel komplexe Arbeit leisten und / oder zu klar messbaren Ergebnissen führen, sind im Allgemeinen leicht testbar. Daher unterscheidet sich das Testen vom Debuggen. In diesen Fällen impliziert das Testen nachdrücklich eine verfahrensbasierte, formalisierte Methode zur Bestätigung oder Nichtbestätigung der Übereinstimmung von Erwartungen und tatsächlichem Output. Das Testen findet ständig statt und informiert uns gelegentlich über die Notwendigkeit des Debuggens.
Es wäre schön, wenn dies eine allgegenwärtige Wahrheit wäre. Ich würde es lieben, wenn meine Entwicklungszyklen durch klar definierte Binärausgaben (rot, grün) begrenzt wären, aber ...
In meinem Fall (der zugegebenermaßen besonders ist - ich arbeite zu 98% allein an kleinen, mittelgroßen, unterfinanzierten, webbasierten, datenorientierten Unternehmensadministrationssystemen) kann ich einfach nicht wirklich sehen, wie TDD mir möglicherweise helfen könnte. Oder besser gesagt, "Debuggen" und "Testen" sind praktisch gleich.
Hauptsächlich, obwohl die Verwendung des Begriffs "Testen" die Methodik von TDD impliziert / eng damit zusammenhängt.
Ich weiß, dass dies eine völlig unzeitgeistige "meide den Ungläubigen, meide, meide" ist, eine verabscheuungswürdige, nicht coole Sache zu sagen. Aber wenn ich an meinen Kontext denke, mit einem praktischen Hut auf, sehe ich in meiner wildesten Fantasie nicht einmal vage, wie TDD mir möglicherweise helfen könnte, meinen Kunden ein besseres Preis-Leistungs-Verhältnis zu bieten.
Oder besser gesagt, ich stimme der allgemeinen Annahme, dass "Testen" ein formaler Code-basierter Prozess ist, überhaupt nicht zu.
Mein grundlegender Einwand (anwendbar in meinem speziellen * Kontext *) ist, dass ...
Wenn ich keinen Code schreiben kann, der zuverlässig funktioniert - wie zum Teufel soll ich dann Code schreiben, der zuverlässig funktioniert, um den vermutlich unterdurchschnittlichen Code zu testen ?
Für mich habe ich noch nie ein Beispiel oder Argument gesehen, das mich (in meinem speziellen Kontext) so begeistert hat , dass ich überhaupt über das Schreiben eines einzelnen Tests nachdenken konnte. Ich könnte gerade einen lächerlich unwesentlichen Testcode schreiben, vielleicht "gibt mein Repository einen Benutzer zurück Entität mit Name == X, wenn ich genau - und nur - danach frage? ", aber es ist wahrscheinlich nützlicher, wenn ich dieses Streaming schreibe, vielleicht ist das Internet wirklich nur ein bloßes, dummes Ausspritzen. Selbstbefriedigend-wild-unter-informiert-Blut-kochend-bedeutend-verschwenderisch-alberner Müll, aber ich habe nur das Bedürfnis, hier den Anwalt des Teufels zu spielen. (Ich hoffe, jemand zeigt mir das Licht und bekehrt mich. Vielleicht bietet dies meinen Kunden ein besseres Preis-Leistungs-Verhältnis?)
Wahrscheinlich ist "Debuggen" manchmal dasselbe wie "Testen". Damit meine ich wirklich, dass ich in meinem täglichen Arbeitsleben mindestens ein Drittel meiner Zeit damit verbringe, mit der lokalen Version meines Systems in verschiedenen Browsern herumzuspielen, verzweifelt verschiedene verrückte Dinge auszuprobieren, um meine Arbeit zu brechen und dann Nachforschungen anzustellen die Gründe, warum es fehlgeschlagen ist und sie zu korrigieren.
Ich stimme zu 100% dem offensichtlichen Nutzen des TDD-Mantras "Rot / Grün / Refaktor" zu, aber für mich (Arbeiten in Low-Med-Budget, Solo-Entwickler-RIA-Land) würde ich es wirklich lieben, wenn jemand mir bitte zeigt, wie ich könnte möglicherweise , logisch und äußerst realistisch keine zusätzlichen Wert erhalten von mehr schreiben ( nur als potentiell fehlerhaft testen Code) als ich von tatsächlich mit der vollen (und im wesentlichen nur) Ausgabe meiner Bemühungen in Wechselwirkung, die Wechselwirkung echten menschlichen wesentlichen gebunden sind.
Wenn Entwickler über "Testen" sprechen, bedeutet dies für mich im Allgemeinen TDD.
Ich versuche zu codieren, als ob es Tests gäbe. Ich denke, alle Muster / Praktiken und Trends, die all diese testorientierte Entwicklung gefördert hat, sind fantastisch und schön, aber für mich in meiner kleinen Welt bedeutet "Testen" nicht, mehr Code zu schreiben, sondern tatsächlich Das Testen der realen Welt gibt es auf eine nahezu realistische Weise aus, und das ist praktisch dasselbe wie das Debuggen, oder vielmehr ist die aktive Änderung hier das "Debuggen", das ein direktes Ergebnis menschlicher, ausgabezentrierter, nicht automatisierter "Tests" ist. Dies steht im Gegensatz zu der allgemein akzeptierten Ansicht, "Testen" als etwas Automatisiertes und Formales und "Debuggen" als etwas Menschliches und Ad-hoces oder Unstrukturiertes.
Wenn das Ziel wirklich ein gutes Preis-Leistungs-Verhältnis ist und Sie webbasierte interaktive Anwendungen erstellen, sind die Webseiten die Ausgabe der Bemühungen und im Wesentlichen die Art und Weise, wie sie auf menschliche Eingaben reagieren. Daher wird "Testen" am besten durch Testen erreicht diese Webseiten durch echte menschliche Interaktion. Wenn diese Interaktion zu unerwarteten oder unerwünschten Ausgaben führt, tritt "Debugging" auf. Das Debuggen ist auch eng mit der Idee der Echtzeitprüfung des Programmstatus verbunden. Testen ist im Allgemeinen mit Automatisierung verbunden, was meiner Meinung nach oft eine unglückliche Verbindung ist.
Wenn das Ziel wirklich ein Wert für den Aufwand ist und automatisierte Tests effizient und äußerst vorteilhaft sind, während das Debuggen entweder nur eine Ausgabe dieser Tests oder ein schlechter Ersatz für automatisierte Tests ist, warum ist dann die am zweithäufigsten besuchte Website der Welt (Facebook)? ) so oft mit verblüffend offensichtlichen (für Benutzer, aber eindeutig nicht für das Testteam und den Testcode) Fehlern durchsetzt?
Vielleicht liegt es daran, dass sie sich auf die beruhigenden grünen Lichter konzentrieren und vergessen, die Ergebnisse ihrer Arbeit tatsächlich zu nutzen?
Denken zu viele Entwickler, dass Sie mit Code testen und gelegentlich mit der IDE debuggen, weil ein Symbol rot wird und Sie nicht herausfinden können, warum? Ich denke, mit diesen Worten sind unglückliche Werturteile verbunden, die im Allgemeinen die praktische Realität dessen verschleiern, worauf wir uns konzentrieren sollten, um die Lücken zwischen Erwartungen und Ergebnissen zu schließen.