Wir schreiben Tests, um die Richtigkeit des Verhaltens eines Programms zu überprüfen.
Das Überprüfen der Richtigkeit des Verhaltens eines Programms durch Überprüfen des Inhalts von Ausgabeanweisungen mit Ihren Augen ist ein manueller oder genauer gesagt ein visueller Prozess.
Das könnte man argumentieren
Die visuelle Inspektion funktioniert . Ich überprüfe, ob der Code für diese Szenarien das tut, was er tun soll. Sobald ich sehe, dass er korrekt ist, können wir loslegen.
Zunächst einmal ist es großartig, dass Sie daran interessiert sind, ob der Code richtig funktioniert oder nicht. Das ist gut. Du bist der Kurve voraus! Leider gibt es Probleme mit diesem Ansatz.
Das erste Problem bei der Sichtprüfung besteht darin, dass Sie einen schweren Schweißunfall haben und nicht mehr in der Lage sind, die Richtigkeit Ihres Codes erneut zu überprüfen.
Das zweite Problem ist, dass das verwendete Augenpaar eng mit dem Gehirn des Augenbesitzers verbunden ist. Wenn der Autor des Codes auch die Augen besitzt, die für den visuellen Inspektionsprozess verwendet werden, hängt der Prozess der Überprüfung der Korrektheit vom Wissen über das Programm ab, das im Gehirn des visuellen Inspektors verinnerlicht ist.
Es ist schwierig für ein neues Augenpaar, die Richtigkeit des Codes zu überprüfen, nur weil sie nicht mit dem Gehirn des ursprünglichen Codierers zusammenarbeiten. Der Besitzer des zweiten Augenpaares muss sich mit dem ursprünglichen Autor des Codes unterhalten , um den betreffenden Code vollständig zu verstehen. Konversation als Mittel zum Wissensaustausch ist notorisch unzuverlässig. Ein Punkt, der umstritten ist, wenn der Original-Codierer für die neuen Paaraugen nicht verfügbar ist. In diesem Fall muss das neue Augenpaar den Originalcode lesen.
Das Lesen des Codes anderer Personen, der nicht durch Unit-Tests abgedeckt ist, ist schwieriger als das Lesen von Code, dem Unit-Tests zugeordnet sind. Im besten Fall ist das Lesen des Codes anderer Leute eine schwierige Aufgabe, im schlimmsten Fall ist dies die schwierigste Aufgabe in der Softwareentwicklung. Es gibt einen Grund, warum Arbeitgeber bei der Werbung für offene Stellen betonen, dass ein Projekt auf der grünen Wiese (oder brandneu) ist. Das Schreiben von Code von Grund auf ist einfacher als das Ändern von vorhandenem Code und lässt den ausgeschriebenen Job für potenzielle Mitarbeiter attraktiver erscheinen.
Beim Unit-Test teilen wir den Code in seine Bestandteile auf. Für jede Komponente legen wir dann unseren Stand fest, wie sich das Programm verhalten soll . Jeder Komponententest erzählt eine Geschichte darüber, wie sich dieser Teil des Programms in einem bestimmten Szenario verhalten sollte. Jeder Komponententest ist wie eine Klausel in einem Vertrag, die beschreibt, was aus Sicht des Kundencodes geschehen soll.
Dies bedeutet dann, dass ein neues Augenpaar zwei Stränge lebendiger und genauer Dokumentation des betreffenden Codes enthält.
Zuerst haben sie den Code selbst, die Implementierung, wie der Code gemacht wurde ; Zweitens haben sie das gesamte Wissen, das der ursprüngliche Codierer in einer Reihe formaler Aussagen beschrieben hat, die die Geschichte darüber erzählen, wie sich dieser Code verhalten soll.
Unit-Tests erfassen und beschreiben formal das Wissen, das der ursprüngliche Autor bei der Implementierung der Klasse besaß. Sie enthalten eine Beschreibung des Verhaltens dieser Klasse bei Verwendung durch einen Client.
Sie stellen zu Recht die Nützlichkeit dieses Vorgangs in Frage, da es möglich ist, nutzlose Komponententests zu schreiben, die nicht den gesamten fraglichen Code abdecken, veraltet oder veraltet sind usw. Wie stellen wir sicher, dass Unit-Tests den Prozess eines sachkundigen, gewissenhaften Autors, der die Ausgabeanweisungen seines Codes zur Laufzeit visuell überprüft, nicht nur nachahmen, sondern auch verbessern? Schreiben Sie zuerst den Komponententest und dann den Code, um diesen Test zu bestehen. Wenn Sie fertig sind, lassen Sie die Computer die Tests ausführen. Sie sind schnell und eignen sich hervorragend für sich wiederholende Aufgaben. Sie sind ideal für den Job geeignet.
Stellen Sie die Testqualität sicher, indem Sie sie jedes Mal überprüfen, wenn Sie den Code berühren, den sie testen, und die Tests für jeden Build ausführen. Wenn ein Test fehlschlägt, beheben Sie ihn sofort.
Wir automatisieren den Prozess der Ausführung von Tests so, dass sie jedes Mal ausgeführt werden, wenn wir ein Projekt erstellen. Wir automatisieren auch die Erstellung von Codeabdeckungsberichten, in denen angegeben ist, wie viel Prozent des Codes von Tests abgedeckt und ausgeführt werden. Wir streben hohe Prozentsätze an. Einige Unternehmen verhindern, dass Codeänderungen in die Quellcodeverwaltung eingecheckt werden, wenn nicht genügend Komponententests geschrieben wurden, um Änderungen im Verhalten des Codes zu beschreiben. In der Regel überprüft ein zweites Augenpaar die Codeänderungen in Verbindung mit dem Autor der Änderungen. Der Prüfer wird die Änderungen durchgehen, um sicherzustellen, dass die Änderungen verständlich sind und durch Tests ausreichend abgedeckt werden. Der Überprüfungsprozess ist also manuell. Wenn die Tests (Einheiten- und Integrationstests und möglicherweise Benutzerakzeptanztests) diesen manuellen Überprüfungsprozess bestehen, werden sie Teil des automatischen Erstellungsprozesses. Diese werden jedes Mal ausgeführt, wenn eine Änderung eingecheckt wird. A.kontinuierliche Integration Der Server führt diese Aufgabe im Rahmen des Erstellungsprozesses aus.
Tests, die automatisch ausgeführt werden, behalten die Integrität des Codeverhaltens bei und verhindern , dass zukünftige Änderungen an der Codebasis den Code beschädigen .
Durch das Bereitstellen von Tests können Sie Code aggressiv neu faktorisieren, da Sie große Codeverbesserungen sicher durchführen können, wenn Sie wissen, dass Ihre Änderungen vorhandene Tests nicht beschädigen.
Test Driven Development hat eine Einschränkung : Sie müssen Code schreiben, um ihn testbar zu machen. Dies beinhaltet das Codieren in Schnittstellen und die Verwendung von Techniken wie Dependency Injection, um kollaborierende Objekte zu instanziieren. Schauen Sie sich die Arbeit von Kent Beck an , der TDD sehr gut beschreibt. Suchen Sie nach Codierung für Schnittstellen und studieren SieDesignmuster
