Was ist Unit Testing? [geschlossen]

Ich habe viele Fragen gesehen, in denen gefragt wurde, wie ein Unit-Test in einer bestimmten Sprache durchgeführt werden soll, aber keine Frage, was, was, warum und wann.

• Was ist es?
• Was macht es für mich?
• Warum sollte ich es benutzen?
• Wann soll ich es benutzen (auch wenn nicht)?
• Was sind einige häufige Fallstricke und Missverständnisse

Beim Unit-Test werden grob gesagt Teile Ihres Codes isoliert mit dem Testcode getestet. Die unmittelbaren Vorteile, die mir in den Sinn kommen, sind:

• Das Ausführen der Tests wird automatisierbar und wiederholbar
• Sie können auf einer viel detaillierteren Ebene testen als Point-and-Click-Tests über eine GUI

Beachten Sie, dass Ihr Testcode, wenn er in eine Datei schreibt, eine Datenbankverbindung öffnet oder etwas über das Netzwerk ausführt, besser als Integrationstest kategorisiert wird. Integrationstests sind eine gute Sache, sollten aber nicht mit Komponententests verwechselt werden. Der Unit-Test-Code sollte kurz, süß und schnell auszuführen sein.

Eine andere Möglichkeit, Unit-Tests zu betrachten, besteht darin, dass Sie die Tests zuerst schreiben. Dies wird als Test-Driven Development (kurz TDD) bezeichnet. TDD bringt zusätzliche Vorteile:

• Sie schreiben keinen spekulativen Code "Ich könnte das in Zukunft brauchen" - gerade genug, um die Tests zu bestehen
• Der von Ihnen geschriebene Code wird immer durch Tests abgedeckt
• Wenn Sie zuerst den Test schreiben, müssen Sie darüber nachdenken, wie Sie den Code aufrufen möchten, was auf lange Sicht normalerweise das Design des Codes verbessert.

Wenn Sie jetzt keine Unit-Tests durchführen, empfehle ich Ihnen, damit zu beginnen. Holen Sie sich ein gutes Buch, praktisch jedes xUnit-Buch reicht aus, da die Konzepte sehr gut zwischen ihnen übertragbar sind.

Manchmal kann das Schreiben von Unit-Tests schmerzhaft sein. Wenn es so wird, versuchen Sie, jemanden zu finden, der Ihnen hilft, und widerstehen Sie der Versuchung, "nur den verdammten Code zu schreiben". Unit-Tests ähneln dem Abwasch. Es ist nicht immer angenehm, aber es hält Ihre metaphorische Küche sauber und Sie möchten wirklich, dass sie sauber ist. :) :)

Bearbeiten: Ein Missverständnis fällt mir ein, obwohl ich nicht sicher bin, ob es so häufig ist. Ich habe einen Projektmanager sagen hören, dass Unit-Tests das Team dazu gebracht haben, den gesamten Code zweimal zu schreiben. Wenn es so aussieht und sich so anfühlt, machst du es falsch. Das Schreiben der Tests beschleunigt normalerweise nicht nur die Entwicklung, sondern gibt Ihnen auch einen praktischen Indikator "Jetzt bin ich fertig", den Sie sonst nicht hätten.

Ich bin nicht anderer Meinung als Dan (obwohl eine bessere Wahl vielleicht darin besteht, nicht zu antworten) ... aber ...

Beim Unit-Test wird Code geschrieben, um das Verhalten und die Funktionalität Ihres Systems zu testen.

Natürlich verbessern Tests die Qualität Ihres Codes, aber das ist nur ein oberflächlicher Vorteil von Unit-Tests. Die wirklichen Vorteile sind:

1. Erleichtern Sie das Ändern der technischen Implementierung, ohne das Verhalten zu ändern (Refactoring). Ordnungsgemäß getesteter Code kann aggressiv überarbeitet / bereinigt werden, ohne dass die Wahrscheinlichkeit besteht, dass etwas kaputt geht, ohne es zu bemerken.
2. Geben Sie Entwicklern Vertrauen, wenn Sie Verhalten hinzufügen oder Korrekturen vornehmen.
3. Dokumentieren Sie Ihren Code
4. Geben Sie Bereiche Ihres Codes an, die eng miteinander verbunden sind. Es ist schwierig, einen eng gekoppelten Unit-Test-Code zu erstellen
5. Bieten Sie eine Möglichkeit, Ihre API zu verwenden und frühzeitig nach Schwierigkeiten zu suchen
6. Zeigt Methoden und Klassen an, die nicht sehr zusammenhängend sind

Sie sollten einen Unit-Test durchführen, da es in Ihrem Interesse liegt, Ihrem Kunden ein wartbares und qualitativ hochwertiges Produkt zu liefern.

Ich würde vorschlagen, dass Sie es für jedes System oder einen Teil eines Systems verwenden, das das reale Verhalten modelliert. Mit anderen Worten, es eignet sich besonders gut für die Unternehmensentwicklung. Ich würde es nicht für Wegwerf- / Hilfsprogramme verwenden. Ich würde es nicht für Teile eines Systems verwenden, deren Test problematisch ist (Benutzeroberfläche ist ein häufiges Beispiel, aber das ist nicht immer der Fall).

Die größte Gefahr besteht darin, dass Entwickler eine zu große Einheit testen oder eine Methode als Einheit betrachten. Dies gilt insbesondere dann, wenn Sie Inversion of Control nicht verstehen. In diesem Fall werden Ihre Komponententests immer zu End-to-End-Integrationstests. Unit-Test sollte individuelles Verhalten testen - und die meisten Methoden haben viele Verhaltensweisen.

Das größte Missverständnis ist, dass Programmierer nicht testen sollten. Das glauben nur schlechte oder faule Programmierer. Sollte der Typ, der Ihr Dach baut, es nicht testen? Sollte der Arzt, der eine Herzklappe ersetzt, die neue Klappe nicht testen? Nur ein Programmierer kann testen, ob sein Code das tut, was er beabsichtigt hat (QS kann Randfälle testen - wie sich Code verhält, wenn er aufgefordert wird, Dinge zu tun, die der Programmierer nicht beabsichtigt hat, und der Client kann einen Abnahmetest durchführen - tut der Code was der Kunde dafür bezahlt hat)

Der Hauptunterschied zwischen Unit-Tests und "nur ein neues Projekt öffnen und diesen spezifischen Code testen" besteht darin, dass es automatisiert und somit wiederholbar ist .

Wenn Sie Ihren Code manuell testen, kann dies Sie davon überzeugen, dass der Code einwandfrei funktioniert - in seinem aktuellen Zustand . Aber was ist mit einer Woche später, als Sie eine geringfügige Änderung daran vorgenommen haben? Sind Sie bereit, es erneut von Hand zu testen, wenn sich etwas an Ihrem Code ändert? Höchstwahrscheinlich nicht :-(

Aber wenn Sie Ihre Tests jederzeit ausführen, mit einem einzigen Klick, genau die gleiche Art und Weise, innerhalb weniger Sekunden , dann sie werden Ihnen sofort zeigen , wenn etwas kaputt ist. Und wenn Sie die Komponententests auch in Ihren automatisierten Erstellungsprozess integrieren, werden Sie auf Fehler aufmerksam gemacht, selbst wenn eine scheinbar völlig unabhängige Änderung in einem entfernten Teil der Codebasis etwas kaputt gemacht hat - wenn Ihnen nicht einmal einfällt, dass dies der Fall ist eine Notwendigkeit, diese bestimmte Funktionalität erneut zu testen.

Dies ist der Hauptvorteil von Unit-Tests gegenüber Hand-Tests. Aber warte, es gibt noch mehr:

• Unit-Tests verkürzen die Rückkopplungsschleife für die Entwicklung erheblich : Bei einer separaten Testabteilung kann es Wochen dauern, bis Sie feststellen, dass ein Fehler in Ihrem Code vorliegt. Zu diesem Zeitpunkt haben Sie bereits einen Großteil des Kontexts vergessen, sodass es Stunden dauern kann den Fehler finden und beheben; OTOH mit Unit-Tests, der Rückkopplungszyklus wird in Sekunden gemessen, und der Fehlerbehebungsprozess verläuft normalerweise nach dem Motto "Oh, ich habe vergessen, hier nach diesem Zustand zu suchen" :-)
• Unit-Tests dokumentieren effektiv (Ihr Verständnis) das Verhalten Ihres Codes
• Unit-Tests zwingen Sie dazu, Ihre Designentscheidungen neu zu bewerten, was zu einem einfacheren und saubereren Design führt

Unit-Test-Frameworks erleichtern Ihnen das Schreiben und Ausführen Ihrer Tests.

An der Universität wurde mir nie Unit Testing beigebracht, und ich brauchte eine Weile, um es zu "bekommen". Ich las darüber, ging zu "ah, richtig, automatisiertes Testen, das könnte cool sein, denke ich" und vergaß es dann.

Es hat ziemlich lange gedauert, bis ich den Punkt wirklich herausgefunden habe: Nehmen wir an, Sie arbeiten an einem großen System und schreiben ein kleines Modul. Es kompiliert, Sie testen es, es funktioniert hervorragend, Sie fahren mit der nächsten Aufgabe fort. Neun Monate später und zwei Versionen später nimmt jemand anderes eine Änderung an einem scheinbar nicht verwandten Teil des Programms vor und es bricht das Modul. Schlimmer noch, sie testen ihre Änderungen und ihr Code funktioniert, aber sie testen Ihr Modul nicht. Zum Teufel, sie wissen vielleicht nicht einmal, dass Ihr Modul existiert .

Und jetzt haben Sie ein Problem: Der defekte Code befindet sich im Kofferraum und niemand weiß es. Der beste Fall ist, dass ein interner Tester es findet, bevor Sie es versenden, aber es ist teuer, Code so spät im Spiel zu reparieren. Und wenn kein interner Tester es findet ... nun, das kann in der Tat sehr teuer werden.

Die Lösung sind Unit-Tests. Sie werden Probleme bekommen, wenn Sie Code schreiben - was in Ordnung ist -, aber Sie hätten das von Hand tun können. Die wirkliche Auszahlung ist, dass sie neun Monate später Probleme haben werden, wenn Sie jetzt an einem völlig anderen Projekt arbeiten, aber ein Sommerpraktikant glaubt, dass es ordentlicher aussehen wird, wenn diese Parameter in alphabetischer Reihenfolge vorliegen - und dann der Komponententest Sie haben geschrieben, dass der Rückweg fehlschlägt, und jemand wirft Dinge auf den Praktikanten, bis er die Parameterreihenfolge zurück ändert.Das ist das "Warum" von Unit-Tests. :-)

Hier einige der wichtigsten "Glühbirnen" -Beobachtungen, die mich bei meinen ersten vorläufigen Schritten auf dem Weg zur TDD-Erleuchtung beeindruckt haben (keine originellen oder notwendigerweise neuen Nachrichten) ...

1. TDD bedeutet NICHT, doppelt so viel Code zu schreiben. Testcode ist normalerweise ziemlich schnell und schmerzlos zu schreiben und ist ein wichtiger Teil Ihres Designprozesses und kritisch.

2. TDD hilft Ihnen zu erkennen, wann Sie mit dem Codieren aufhören müssen! Ihre Tests geben Ihnen die Gewissheit, dass Sie vorerst genug getan haben, und können aufhören zu optimieren und mit dem nächsten Schritt fortfahren.

3. Die Tests und der Code arbeiten zusammen, um einen besseren Code zu erzielen. Ihr Code könnte schlecht / fehlerhaft sein. Ihr TEST könnte schlecht / fehlerhaft sein. In TDD setzen Sie auf die Wahrscheinlichkeit, dass BEIDE schlecht / fehlerhaft sind, ziemlich gering. Oft ist es der Test, der repariert werden muss, aber das ist immer noch ein gutes Ergebnis.

4. TDD hilft bei der Kodierung von Verstopfung. Sie kennen das Gefühl, dass Sie so viel zu tun haben, dass Sie kaum wissen, wo Sie anfangen sollen? Es ist Freitagnachmittag, wenn Sie nur noch ein paar Stunden zögern ... Mit TDD können Sie sehr schnell ausarbeiten, was Sie zu tun glauben, und Ihre Codierung wird schnell umgesetzt. Ebenso wie Laborratten denke ich, dass wir alle auf dieses große grüne Licht reagieren und härter daran arbeiten, es wieder zu sehen!

5. In ähnlicher Weise können diese Designer-Typen SEHEN, woran sie arbeiten. Sie können eine Saft- / Zigaretten- / iPhone-Pause einlegen und zu einem Monitor zurückkehren, der ihnen sofort einen visuellen Hinweis darauf gibt, wo sie angekommen sind. TDD gibt uns etwas Ähnliches. Es ist einfacher zu sehen, wo wir angekommen sind, wenn das Leben eingreift ...

6. Ich denke, es war Fowler, der sagte: "Unvollkommene Tests, die häufig ausgeführt werden, sind viel besser als perfekte Tests, die überhaupt nicht geschrieben werden." Ich interpretiere dies als Erlaubnis, Tests zu schreiben, bei denen ich denke, dass sie am nützlichsten sind, selbst wenn der Rest meiner Codeabdeckung absolut unvollständig ist.

7. TDD hilft auf alle möglichen überraschenden Arten. Gute Unit-Tests können dabei helfen, zu dokumentieren, was etwas tun soll. Sie können Ihnen dabei helfen, Code von einem Projekt in ein anderes zu migrieren, und Ihnen ein ungerechtfertigtes Gefühl der Überlegenheit gegenüber Ihren nicht testenden Kollegen vermitteln :)

Diese Präsentation ist eine hervorragende Einführung in alle leckeren Güteprüfungen.

Ich möchte das Buch xUnit Testing Patterns von Gerard Meszaros empfehlen. Es ist groß, aber eine großartige Ressource für Unit-Tests. Hier ist ein Link zu seiner Website, auf der er die Grundlagen des Unit-Tests erläutert. http://xunitpatterns.com/XUnitBasics.html

Ich benutze Unit-Tests, um Zeit zu sparen.

Beim Erstellen von Geschäftslogik- (oder Datenzugriffs-) Testfunktionen kann häufig das Eingeben von Daten in viele Bildschirme erforderlich sein, die möglicherweise noch nicht abgeschlossen sind. Die Automatisierung dieser Tests spart Zeit.

Unit Tests sind für mich eine Art modularisiertes Testgeschirr. Es gibt normalerweise mindestens einen Test pro öffentlicher Funktion. Ich schreibe zusätzliche Tests, um verschiedene Verhaltensweisen abzudecken.

Alle Sonderfälle, an die Sie bei der Entwicklung des Codes gedacht haben, können in den Unit-Tests im Code aufgezeichnet werden. Die Komponententests werden auch zu einer Quelle für Beispiele zur Verwendung des Codes.

Es ist für mich viel schneller festzustellen, dass mein neuer Code in meinen Komponententests etwas kaputt macht, als den Code einzuchecken und einen Front-End-Entwickler ein Problem finden zu lassen.

Für Datenzugriffstests versuche ich, Tests zu schreiben, die entweder keine Änderungen aufweisen oder nach sich selbst bereinigen.

Unit-Tests werden nicht alle Testanforderungen erfüllen können. Sie können Entwicklungszeit sparen und Kernteile der Anwendung testen.

Das ist meine Einstellung dazu. Ich würde sagen, Unit-Tests sind die Praxis, Softwaretests zu schreiben, um zu überprüfen, ob Ihre echte Software das tut, wofür sie gedacht ist. Dies begann mit jUnit in der Java-Welt und hat sich auch mit SimpleTest und phpUnit zu einer Best Practice in PHP entwickelt . Es ist eine Kernpraxis der extremen Programmierung und hilft Ihnen sicherzustellen, dass Ihre Software nach der Bearbeitung immer noch wie beabsichtigt funktioniert. Wenn Sie über eine ausreichende Testabdeckung verfügen, können Sie schnell größere Umgestaltungen, Fehlerbehebungen oder Funktionen hinzufügen, ohne befürchten zu müssen, dass andere Probleme auftreten.

Am effektivsten ist es, wenn alle Komponententests automatisch ausgeführt werden können.

Unit-Tests sind im Allgemeinen mit der OO-Entwicklung verbunden. Die Grundidee besteht darin, ein Skript zu erstellen, das die Umgebung für Ihren Code einrichtet und dann ausübt. Sie schreiben Zusicherungen, geben die beabsichtigte Ausgabe an, die Sie erhalten sollen, und führen dann Ihr Testskript mit einem Framework wie dem oben genannten aus.

Das Framework führt alle Tests für Ihren Code aus und meldet dann den Erfolg oder Misserfolg jedes Tests. phpUnit wird standardmäßig über die Linux-Befehlszeile ausgeführt, obwohl dafür HTTP-Schnittstellen verfügbar sind. SimpleTest ist von Natur aus webbasiert und viel einfacher zu starten, IMO. In Kombination mit xDebug kann phpUnit Ihnen automatisierte Statistiken zur Codeabdeckung liefern, die manche Leute sehr nützlich finden.

Einige Teams schreiben Hooks aus ihrem Subversion-Repository, sodass Unit-Tests automatisch ausgeführt werden, wenn Sie Änderungen festschreiben.

Es wird empfohlen, Ihre Komponententests im selben Repository wie Ihre Anwendung zu speichern.

Bibliotheken wie NUnit , xUnit oder JUnit sind nur obligatorisch, wenn Sie Ihre Projekte mit dem von Kent Beck verbreiteten TDD- Ansatz entwickeln möchten :

Sie können Introduction to Test Driven Development (TDD) oder Kent Becks Buch Test Driven Development: By Example lesen .

Wenn Sie sicher sein möchten, dass Ihre Tests einen "guten" Teil Ihres Codes abdecken , können Sie Software wie NCover , JCover , PartCover oder was auch immer verwenden. Sie geben Ihnen den Prozentsatz der Abdeckung Ihres Codes an. Je nachdem, wie gut Sie mit TDD vertraut sind, werden Sie wissen, ob Sie es gut genug geübt haben :)

Unit-Testing ist das Testen einer Codeeinheit (z. B. einer einzelnen Funktion), ohne dass die Infrastruktur erforderlich ist, auf die sich diese Codeeinheit stützt. dh testen Sie es isoliert.

Wenn beispielsweise die zu testende Funktion eine Verbindung zu einer Datenbank herstellt und ein Update durchführt, möchten Sie dieses Update in einem Komponententest möglicherweise nicht durchführen. Sie würden, wenn es ein Integrationstest wäre, aber in diesem Fall ist es nicht.

Ein Komponententest würde also die Funktionalität der "Funktion", die Sie testen, ohne Nebenwirkungen der Datenbankaktualisierung ausüben.

Angenommen, Ihre Funktion hat einige Zahlen aus einer Datenbank abgerufen und dann eine Standardabweichungsberechnung durchgeführt. Was versuchst du hier zu testen? Dass die Standardabweichung korrekt berechnet wird oder dass die Daten aus der Datenbank zurückgegeben werden?

In einem Komponententest möchten Sie nur testen, ob die Standardabweichung korrekt berechnet wurde. In einem Integrationstest möchten Sie die Standardabweichungsberechnung und den Datenbankabruf testen.

Beim Unit-Test geht es darum, Code zu schreiben, der Ihren Anwendungscode testet.

Die Einheit Teil des Namens befasst sich mit der Absicht, jeweils kleine Codeeinheiten (z. B. eine Methode) zu testen.

xUnit hilft bei diesen Tests - es handelt sich um Frameworks, die dabei helfen. Ein Teil davon sind automatisierte Testläufer, die Ihnen sagen, welche Tests fehlschlagen und welche bestehen.

Sie haben auch die Möglichkeit, allgemeinen Code einzurichten, den Sie in jedem Test vor der Hand benötigen, und ihn abzureißen, wenn alle Tests abgeschlossen sind.

Sie können einen Test durchführen lassen, um zu überprüfen, ob eine erwartete Ausnahme ausgelöst wurde, ohne den gesamten try catch-Block selbst schreiben zu müssen.

Ich denke, der Punkt, den Sie nicht verstehen, ist, dass Unit-Test-Frameworks wie NUnit (und dergleichen) Ihnen bei der Automatisierung kleiner bis mittlerer Tests helfen werden. Normalerweise können Sie die Tests in einer GUI ausführen (dies ist beispielsweise bei NUnit der Fall ), indem Sie einfach auf eine Schaltfläche klicken und dann - hoffentlich - sehen, dass der Fortschrittsbalken grün bleibt. Wenn es rot wird, zeigt Ihnen das Framework, welcher Test fehlgeschlagen ist und was genau schief gelaufen ist. In einem normalen Komponententest verwenden Sie häufig Zusicherungen, z. B. Assert.AreEqual(expectedValue, actualValue, "some description")Wenn die beiden Werte ungleich sind, wird ein Fehler mit der Meldung "Beschreibung: Erwarteter <erwarteter Wert>, aber <tatsächlicher Wert>" angezeigt.

Zusammenfassend lässt sich sagen, dass Unit-Tests das Testen für Entwickler schneller und komfortabler machen. Sie können alle Komponententests ausführen, bevor Sie neuen Code festschreiben, damit Sie den Erstellungsprozess anderer Entwickler im selben Projekt nicht unterbrechen.

Verwenden Sie Testivus . Alles was du wissen musst ist genau dort :)

Unit-Tests sind eine Vorgehensweise, um sicherzustellen, dass sich die zu implementierende Funktion oder das zu implementierende Modul wie erwartet verhält (Anforderungen) und um sicherzustellen, dass sie sich in Szenarien wie Randbedingungen und ungültigen Eingaben verhalten.

xUnit , NUnit , mbUnit usw. sind Tools, die Ihnen beim Schreiben der Tests helfen.

Test Driven Development hat den Begriff Unit Test übernommen. Als Oldtimer werde ich die allgemeinere Definition davon erwähnen.

Unit Test bedeutet auch, eine einzelne Komponente in einem größeren System zu testen. Diese einzelne Komponente kann eine DLL, eine Exe, eine Klassenbibliothek usw. sein. Es kann sich sogar um ein einzelnes System in einer Multisystemanwendung handeln. Letztendlich ist Unit Test also das Testen von allem, was Sie als einzelnes Teil eines größeren Systems bezeichnen möchten.

Sie würden dann zu integrierten Tests oder Systemtests übergehen, indem Sie testen, wie alle Komponenten zusammenarbeiten.

Unabhängig davon, ob es sich um Unit-Tests oder andere Arten von automatisierten Tests (Integration, Laden, UI-Tests usw.) handelt, besteht der Hauptunterschied zu dem, was Sie vorschlagen, darin, dass es automatisiert und wiederholbar ist und keine Humanressourcen erfordert um konsumiert zu werden (= niemand muss die Tests durchführen, sie laufen normalerweise auf Knopfdruck).

Ich ging zu einer Präsentation über Unit-Tests auf der FoxForward 2007 und wurde angewiesen, niemals Unit-Tests durchzuführen, die mit Daten funktionieren. Wenn Sie Live-Daten testen, sind die Ergebnisse unvorhersehbar. Wenn Sie Live-Daten nicht testen, testen Sie den von Ihnen geschriebenen Code nicht. Leider ist das der größte Teil der Codierung, die ich heutzutage mache. :-)

Ich habe kürzlich einen Versuch mit TDD gemacht, als ich eine Routine zum Speichern und Wiederherstellen von Einstellungen schrieb. Zuerst habe ich überprüft, ob ich das Speicherobjekt erstellen kann. Dann hatte es die Methode, die ich aufrufen musste. Dann könnte ich es nennen. Dann, dass ich es Parameter übergeben könnte. Dann könnte ich ihm bestimmte Parameter übergeben. Und so weiter, bis ich endlich überprüft habe, ob die angegebene Einstellung gespeichert wird, kann ich sie für verschiedene Syntaxen ändern und dann wiederherstellen.

Ich bin nicht ans Ende gekommen, weil ich verdammt noch mal die Routine brauchte, aber es war eine gute Übung.

Was tun Sie, wenn Sie einen Haufen Mist bekommen und den Eindruck haben, dass Sie sich in einem fortwährenden Bereinigungszustand befinden, von dem Sie wissen, dass das Hinzufügen neuer Funktionen oder Codes den aktuellen Satz beschädigen kann, da die aktuelle Software wie ein Haus von ist? Karten?

Wie können wir dann Unit-Tests durchführen?

Du fängst klein an. Das Projekt, an dem ich gerade teilgenommen habe, hatte bis vor einigen Monaten keine Unit-Tests. Wenn die Abdeckung so gering war, wählten wir einfach eine Datei ohne Abdeckung aus und klickten auf "Tests hinzufügen".

Im Moment sind wir zu über 40% und es ist uns gelungen, die meisten niedrig hängenden Früchte zu pflücken.

(Das Beste daran ist, dass wir selbst bei dieser geringen Abdeckung bereits auf viele Instanzen des Codes gestoßen sind, die das Falsche getan haben, und die Tests haben es erkannt. Dies ist ein großer Motivator, um die Leute dazu zu bringen, weitere Tests hinzuzufügen.)

Dies beantwortet, warum Sie Unit-Tests durchführen sollten.

Die folgenden 3 Videos behandeln Unit-Tests in Javascript, aber die allgemeinen Prinzipien gelten für die meisten Sprachen.

Unit Testing: Minuten sparen jetzt Stunden später - Eric Mann - https://www.youtube.com/watch?v=_UmmaPe8Bzc

JS Unit Testing (sehr gut) - https://www.youtube.com/watch?v=-IYqgx8JxlU

Schreiben von testbarem JavaScript - https://www.youtube.com/watch?v=OzjogCFO4Zo

Jetzt lerne ich nur etwas über das Thema, daher bin ich möglicherweise nicht 100% korrekt und es steckt mehr dahinter als das, was ich hier beschreibe, aber mein grundlegendes Verständnis von Unit-Tests besteht darin, dass Sie einen Testcode schreiben (der von Ihrem getrennt gehalten wird) Hauptcode), der eine Funktion in Ihrem Hauptcode mit Eingaben (Argumenten) aufruft, die die Funktion benötigt, und der Code dann prüft, ob er einen gültigen Rückgabewert zurückerhält. Wenn ein gültiger Wert zurückgegeben wird, zeigt das Unit-Test-Framework, mit dem Sie die Tests ausführen, grünes Licht an (alles in Ordnung). Wenn der Wert ungültig ist, erhalten Sie ein rotes Licht und können das Problem sofort vor Ihnen beheben Geben Sie den neuen Code für die Produktion frei. Ohne Tests haben Sie den Fehler möglicherweise nicht erkannt.

Sie schreiben also Tests für Ihren aktuellen Code und erstellen den Code so, dass er den Test besteht. Monate später müssen Sie oder eine andere Person die Funktion in Ihrem Hauptcode ändern, da Sie zuvor bereits Testcode für diese Funktion geschrieben haben, den Sie jetzt erneut ausführen und der Test möglicherweise fehlschlägt, weil der Codierer einen logischen Fehler in die Funktion eingeführt oder etwas vollständig zurückgegeben hat anders als das, was diese Funktion zurückgeben soll. Ohne den Test ist dieser Fehler möglicherweise schwer zu finden, da er möglicherweise auch anderen Code betrifft und unbemerkt bleibt.

Auch die Tatsache, dass Sie ein Computerprogramm haben, das Ihren Code durchläuft und testet, anstatt ihn Seite für Seite manuell im Browser auszuführen, spart Zeit (Unit-Test auf Javascript). Angenommen, Sie ändern eine Funktion, die von einem Skript auf einer Webseite verwendet wird, und sie funktioniert gut und gut für den neuen Verwendungszweck. Nehmen wir aber auch aus Gründen der Argumentation an, dass es eine andere Funktion in Ihrem Code gibt, die von dieser neu geänderten Funktion abhängt, damit sie ordnungsgemäß funktioniert. Diese abhängige Funktion funktioniert möglicherweise aufgrund der Änderungen, die Sie an der ersten Funktion vorgenommen haben, nicht mehr. Ohne Tests, die automatisch von Ihrem Computer ausgeführt werden, werden Sie jedoch erst feststellen, dass ein Problem mit dieser Funktion vorliegt, wenn sie tatsächlich ausgeführt wird und Sie'

Um es noch einmal zu wiederholen: Wenn Tests während der Entwicklung Ihrer Anwendung ausgeführt werden, treten diese Probleme beim Codieren auf. Wenn die Tests nicht vorhanden sind, müssen Sie Ihre gesamte Anwendung manuell durchgehen. Selbst dann kann es schwierig sein, den Fehler zu erkennen. Naiv senden Sie ihn in die Produktion und nach einer Weile sendet Ihnen ein freundlicher Benutzer einen Fehlerbericht (der wird nicht so gut sein wie Ihre Fehlermeldungen in einem Testframework).

Es ist ziemlich verwirrend, wenn Sie zum ersten Mal von dem Thema hören und sich denken, teste ich meinen Code nicht bereits? Und der Code, den Sie geschrieben haben, funktioniert so, wie es eigentlich sein soll: "Warum brauche ich ein anderes Framework?" ... Ja, Sie testen Ihren Code bereits, aber ein Computer kann das besser. Sie müssen nur einmal gut genug Tests für eine Funktion / Codeeinheit schreiben, und der Rest wird von der mächtigen CPU für Sie erledigt, anstatt manuell zu überprüfen, ob Ihr gesamter Code noch funktioniert, wenn Sie eine Änderung an vornehmen dein Code.

Außerdem müssen Sie Ihren Code nicht einem Komponententest unterziehen, wenn Sie dies nicht möchten. Dies zahlt sich jedoch aus, wenn Ihre Projekt- / Codebasis mit zunehmender Wahrscheinlichkeit, Fehler einzuführen, größer wird.

Unit-Tests und TDD im Allgemeinen ermöglichen Ihnen kürzere Feedback-Zyklen zu der Software, die Sie schreiben. Anstatt am Ende der Implementierung eine große Testphase durchzuführen, testen Sie schrittweise alles, was Sie schreiben. Dies erhöht die Codequalität erheblich, da Sie sofort sehen, wo möglicherweise Fehler auftreten.