•  08-06-2019
  •  | 
  •  

Frage

Ich habe viele Fragen gesehen, die fragten, „wie“ man Unit-Tests in einer bestimmten Sprache durchführt, aber keine Frage, die fragte „was“, „warum“ und „wann“.

  • Was ist es?
  • Was bringt es mir?
  • Warum sollte ich es verwenden?
  • Wann sollte ich es verwenden (auch wann nicht)?
  • Was sind einige häufige Fallstricke und Missverständnisse?
War es hilfreich?

Lösung

Unter Unit-Tests versteht man grob gesagt das isolierte Testen von Teilen Ihres Codes mit Testcode.Die unmittelbaren Vorteile, die mir in den Sinn kommen, sind:

  • Die Durchführung der Tests wird automatisierbar und wiederholbar
  • Sie können auf einer viel detaillierteren Ebene testen als beim Point-and-Click-Testen über eine GUI

Beachten Sie, dass Ihr Testcode eher als Integrationstest kategorisiert werden sollte, wenn er in eine Datei schreibt, eine Datenbankverbindung öffnet oder etwas über das Netzwerk ausführt.Integrationstests sind eine gute Sache, sollten aber nicht mit Unit-Tests verwechselt werden.Unit-Test-Code sollte kurz, prägnant und schnell ausführbar sein.

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

  • Sie schreiben keinen spekulativen „Ich brauche das vielleicht in Zukunft“-Code – 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 gerade keine Unit-Tests durchführen, empfehle ich Ihnen, damit zu beginnen.Besorgen 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 soweit kommt, versuchen Sie, jemanden zu finden, der Ihnen hilft, und widerstehen Sie der Versuchung, „einfach den verdammten Code zu schreiben“.Unit-Tests ähneln in vielerlei Hinsicht dem Geschirrspülen.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 vorkommt.Ich habe einen Projektmanager sagen hören, dass Unit-Tests dazu führten, dass das Team den gesamten Code zweimal schrieb.Wenn es so aussieht und sich so anfühlt, dann machen Sie es falsch.Das Schreiben der Tests beschleunigt normalerweise nicht nur die Entwicklung, sondern gibt Ihnen auch einen praktischen „Jetzt bin ich fertig“-Indikator, den Sie sonst nicht hätten.

Andere Tipps

Ich widerspreche Dan nicht (obwohl es besser wäre, einfach nicht zu antworten) ... aber ...

Beim Unit-Testen 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 die Änderung der technischen Implementierung und stellen Sie gleichzeitig sicher, dass Sie das Verhalten nicht ändern (Refactoring).Ordnungsgemäß Unit-getesteter Code kann aggressiv umgestaltet/bereinigt werden, ohne dass die Chance groß ist, dass etwas kaputt geht, ohne es zu merken.
  2. Geben Sie Entwicklern Sicherheit, 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, Code zu testen, der eng miteinander verbunden ist
  5. Stellen Sie eine Möglichkeit bereit, Ihre API zu nutzen und frühzeitig nach Schwierigkeiten zu suchen
  6. Zeigt Methoden und Klassen an, die nicht sehr kohärent sind

Sie sollten Unit-Tests 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 jeden Teil eines Systems verwenden, das das Verhalten in der realen Welt 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 es nicht verstehen Umkehrung der Kontrolle – In diesem Fall werden Ihre Unit-Tests immer zu End-to-End-Integrationstests.Unit-Tests sollten individuelle Verhaltensweisen testen – und die meisten Methoden weisen viele Verhaltensweisen auf.

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 (die Qualitätssicherung kann Grenzfälle testen – wie sich der Code verhält, wenn ihm gesagt wird, dass er Dinge tun soll, die der Programmierer nicht beabsichtigt hat), und der Client kann einen Abnahmetest durchführen – tut der Code das? wofür der Kunde dafür bezahlt hat)

Der Hauptunterschied zwischen Unit-Tests und dem „einfachen Öffnen eines neuen Projekts und dem Testen dieses spezifischen Codes“ besteht darin, dass dies der Fall ist automatisiert, daher wiederholbar.

Wenn Sie Ihren Code manuell testen, kann er Sie davon überzeugen, dass der Code perfekt funktioniert – in seinem aktuellen Zustand.Aber wie wäre es eine Woche später, als Sie eine kleine Änderung daran vorgenommen haben?Sind Sie bereit, es jederzeit noch einmal manuell zu testen? irgendetwas Änderungen in Ihrem Code?Höchstwahrscheinlich nicht :-(

Aber wenn du kannst Führen Sie Ihre Tests jederzeit mit einem einzigen Klick auf genau die gleiche Weise und innerhalb weniger Sekunden durch, dann werden sie Wille Zeigen Sie sofort, wenn etwas kaputt ist.Und wenn Sie die Unit-Tests auch in Ihren automatisierten Build-Prozess integrieren, werden Sie selbst dann auf Fehler aufmerksam gemacht, wenn eine scheinbar völlig unabhängige Änderung etwas in einem entfernten Teil der Codebasis kaputt gemacht hat – wenn Ihnen gar nicht in den Sinn gekommen wäre, dass es einen gibt Es besteht die Notwendigkeit, diese bestimmte Funktionalität erneut zu testen.

Dies ist der Hauptvorteil von Unit-Tests gegenüber Handtests.Aber warten Sie, es gibt noch mehr:

  • Unit-Tests Verkürzen Sie die Entwicklungs-Feedbackschleife dramatisch:Mit einer separaten Testabteilung kann es Wochen dauern, bis Sie wissen, 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 zu finden und zu beheben.OTOH mit Unit-Tests, der Feedback-Zyklus wird in Sekunden gemessen und der Fehlerbehebungsprozess verläuft normalerweise nach dem Motto „Oh Scheiße, ich habe vergessen, hier nach dieser Bedingung zu suchen“ :-)
  • Unit-Tests effektiv durchführen dokumentieren (Ihr Verständnis) des Verhaltens Ihres Codes
  • Unit-Tests zwingen Sie dazu, Ihre Designentscheidungen neu zu bewerten, was dazu führt einfacheres, klareres Design

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

Unit Testing wurde mir an der Universität nie beigebracht, und es hat eine Weile gedauert, bis ich es verstanden habe.Ich habe darüber gelesen, dachte: „Ah ja, automatisiertes Testen, das könnte cool sein, schätze ich“, und dann habe ich es vergessen.

Es hat etwas länger gedauert, bis ich es wirklich verstanden habe:Nehmen wir an, Sie arbeiten an einem großen System und schreiben ein kleines Modul.Es wird kompiliert, Sie testen es auf Herz und Nieren, es funktioniert großartig, und Sie fahren mit der nächsten Aufgabe fort.Neun Monate später und zwei Versionen später nimmt jemand anderes eine Änderung vor scheinbar nicht verwandter Teil des Programms, und es bricht das Modul.Schlimmer noch: Sie testen ihre Änderungen und ihr Code funktioniert, aber sie testen Ihr Modul nicht.Verdammt, sie kennen vielleicht nicht einmal Ihr Modul existiert.

Und jetzt haben Sie ein Problem:Der kaputte Code liegt im Kofferraum und niemand weiß es.Im besten Fall findet es ein interner Tester, bevor Sie es ausliefern, aber das Korrigieren des Codes so spät im Spiel ist teuer.Und wenn kein interner Tester es findet, kann das tatsächlich sehr teuer werden.

Die Lösung sind Unit-Tests.Sie werden Probleme erkennen, wenn Sie Code schreiben – was in Ordnung ist – aber Sie hätten das auch von Hand tun können.Der eigentliche Vorteil besteht darin, dass sie neun Monate später auf Probleme stoßen, wenn Sie jetzt an einem völlig anderen Projekt arbeiten, aber ein Sommerpraktikant meint, es würde aufgeräumter aussehen, wenn diese Parameter in alphabetischer Reihenfolge wären – und dann der Unit-Test Sie haben vor langer Zeit geschrieben, schlägt fehl und jemand wirft Dinge auf den Praktikanten, bis er die Parameterreihenfolge wieder ändert. Das ist das „Warum“ von Unit-Tests.:-)

Um auf die philosophischen Vorteile von Unit-Tests und TDD einzugehen, hier ein paar der wichtigsten „Glühbirnen“-Beobachtungen, die mir bei meinen zaghaften ersten Schritten auf dem Weg zur TDD-Erleuchtung auffielen (keine Originalität oder unbedingt eine Neuigkeit) ...

  1. TDD bedeutet NICHT, doppelt so viel Code zu schreiben.Testcode lässt sich in der Regel relativ schnell und schmerzlos schreiben und ist ein wichtiger und entscheidender Bestandteil Ihres Designprozesses.

  2. TDD hilft Ihnen zu erkennen, wann Sie mit dem Codieren aufhören sollten!Ihre Tests geben Ihnen die Gewissheit, dass Sie vorerst genug getan haben und mit den Optimierungen aufhören und mit der nächsten Sache fortfahren können.

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

  4. TDD hilft bei der Codierung von Verstopfung.Kennen Sie das Gefühl, dass Sie so viel zu tun haben und 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 konkretisieren, was Sie Ihrer Meinung nach tun müssen, und Ihre Codierung schnell vorantreiben.Außerdem denke ich, dass wir alle wie Laborratten auf dieses große grüne Licht reagieren und härter daran arbeiten, es wieder zu sehen!

  5. In ähnlicher Weise können diese Designertypen SEHEN, woran sie arbeiten.Sie können eine Saft-/Zigaretten-/iPhone-Pause machen 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 erkennen, wo wir angekommen sind, wenn das Leben dazwischenkommt ...

  6. Ich glaube, es war Fowler, der sagte:„Unvollkommene Tests, die häufig durchgeführt werden, sind viel besser als perfekte Tests, die überhaupt nicht geschrieben werden.“Ich interpretiere dies als Erlaubnis, Tests dort zu schreiben, wo sie meiner Meinung nach am nützlichsten sind, auch wenn der Rest meiner Codeabdeckung erbärmlich unvollständig ist.

  7. TDD hilft auf der ganzen Linie auf überraschende Weise.Gute Unit-Tests können 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 geben :)

Diese Präsentation ist eine ausgezeichnete Einführung in alle Leckereien, die das Testen mit sich bringt.

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

Ich verwende Unit-Tests, um Zeit zu sparen.

Beim Aufbau einer Geschäftslogik (oder eines Datenzugriffs) kann es bei Testfunktionen häufig darum gehen, Dinge in viele Bildschirme einzugeben, die möglicherweise noch nicht abgeschlossen sind.Die Automatisierung dieser Tests spart Zeit.

Für mich sind Unit-Tests eine Art modularisiertes Testgeschirr.In der Regel findet pro öffentlicher Veranstaltung mindestens ein Test statt.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 festgehalten werden.Die Unit-Tests werden auch zu einer Quelle von Beispielen für die Verwendung des Codes.

Es ist für mich viel schneller, zu entdecken, dass mein neuer Code in meinen Unit-Tests 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 aufräumen.

Unit-Tests werden nicht in der Lage sein, alle Testanforderungen zu lösen.Sie können Entwicklungszeit sparen und Kernteile der Anwendung testen.

Das ist meine Meinung dazu.Ich würde sagen, Unit-Tests sind die Praxis, Softwaretests zu schreiben, um zu überprüfen, ob Ihre echte Software das tut, was sie soll.Das begann mit jUnit in der Java-Welt und hat sich auch in PHP als Best Practice etabliert SimpleTest Und phpUnit.Dies ist eine Kernpraxis des Extreme Programming und hilft Ihnen sicherzustellen, dass Ihre Software nach der Bearbeitung immer noch wie vorgesehen funktioniert.Wenn Sie über eine ausreichende Testabdeckung verfügen, können Sie umfangreiche Umgestaltungen, Fehlerbehebungen oder das Hinzufügen von Funktionen schnell durchführen, ohne Angst vor anderen Problemen haben zu müssen.

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

Unit-Tests werden im Allgemeinen mit der OO-Entwicklung in Verbindung gebracht.Die Grundidee besteht darin, ein Skript zu erstellen, das die Umgebung für Ihren Code einrichtet und ihn dann ausführt.Sie schreiben Behauptungen, geben die beabsichtigte Ausgabe an, die Sie erhalten sollen, und führen dann Ihr Testskript mithilfe eines Frameworks wie den oben genannten aus.

Das Framework führt alle Tests für Ihren Code durch und meldet dann den Erfolg oder Misserfolg jedes Tests zurück.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 meiner Meinung nach viel einfacher einzurichten und in Betrieb zu nehmen.In Kombination mit xDebug kann phpUnit Ihnen automatisierte Statistiken zur Codeabdeckung liefern, was 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 empfiehlt sich, Ihre Komponententests im selben Repository wie Ihre Anwendung aufzubewahren.

Bibliothekare mögen NUnit, xUnit oder JUnit sind nur obligatorisch, wenn Sie Ihre Projekte mit dem entwickeln möchten TDD von Kent Beck populär gemachter Ansatz:

Du kannst lesen Einführung in die testgetriebene Entwicklung (TDD) oder Kent Becks Buch Testgetriebene Entwicklung:Zum Beispiel.

Wenn Sie dann sicher sein möchten, dass Ihre Tests einen „guten“ Teil Ihres Codes abdecken, können Sie Software wie verwenden NCover, JCover, PartCover oder Wasauchimmer.Sie werden Ihnen den Abdeckungsprozentsatz Ihres Codes mitteilen.Je nachdem, wie gut Sie sich mit TDD auskennen, werden Sie wissen, ob Sie es gut genug geübt haben :)

Unit-Testing ist das Testen einer Codeeinheit (z. B.eine einzelne Funktion), ohne dass die Infrastruktur erforderlich ist, auf der diese Codeeinheit basiert.d.h.Testen Sie es isoliert.

Wenn beispielsweise die Funktion, die Sie testen, eine Verbindung zu einer Datenbank herstellt und eine Aktualisierung durchführt, möchten Sie diese Aktualisierung in einem Komponententest möglicherweise nicht durchführen.Das würde man tun, wenn es sich um einen Integrationstest handeln würde, aber in diesem Fall ist das nicht der Fall.

Ein Komponententest würde also die in der von Ihnen getesteten „Funktion“ enthaltene Funktionalität ohne Nebenwirkungen der Datenbankaktualisierung ausführen.

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?

Bei einem Unit-Test möchten Sie lediglich testen, ob die Standardabweichung korrekt berechnet wird.In einem Integrationstest möchten Sie die Berechnung der Standardabweichung und den Datenbankabruf testen.

Bei Unit-Tests geht es darum, Code zu schreiben, der Ihren Anwendungscode testet.

Der Einheit Ein Teil des Namens handelt von der Absicht, jeweils kleine Codeeinheiten (z. B. eine Methode) zu testen.

xUnit ist da, um bei diesen Tests zu helfen – es handelt sich um Frameworks, die dabei helfen.Ein Teil davon sind automatisierte Testläufer, die Ihnen sagen, welche Tests fehlschlagen und welche bestanden werden.

Sie verfügen außerdem über die Möglichkeit, allgemeinen Code, den Sie für jeden Test benötigen, vorab einzurichten und ihn nach Abschluss aller Tests wieder zu entfernen.

Sie können einen Test durchführen, 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-Testing-Frameworks wie NUnit (und dergleichen) Ihnen dabei helfen werden automatisieren kleine bis mittelgroße Tests.Normalerweise können Sie die Tests in einer GUI ausführen (das ist der Fall bei NUnit, zum Beispiel), indem Sie einfach auf eine Schaltfläche klicken und dann – hoffentlich – sehen, wie der Fortschrittsbalken grün bleibt.Wenn es rot wird, zeigt Ihnen das Framework an, welcher Test fehlgeschlagen ist und was genau schief gelaufen ist.In einem normalen Unit-Test verwendet man häufig Behauptungen, z.B. Assert.AreEqual(expectedValue, actualValue, "some description") - Wenn also die beiden Werte ungleich sind, wird eine Fehlermeldung mit der Meldung „Beschreibung:“ angezeigt.erwarteter <expectedValue>, war aber <actualValue>".

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

Verwenden Testivus.Alles, was Sie wissen müssen, finden Sie hier :)

Bei Unit-Tests handelt es sich um eine Praxis, um sicherzustellen, dass sich die Funktion oder das Modul, die Sie implementieren möchten, wie erwartet verhält (Anforderungen), und um sicherzustellen, dass sie sich in Szenarien wie Randbedingungen und ungültigen Eingaben verhält.

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

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

Unter Unit Test versteht man auch das Testen einer einzelnen Komponente in einem größeren System.Diese einzelne Komponente könnte eine DLL, eine Exe, eine Klassenbibliothek usw. sein.Es könnte sogar ein einzelnes System in einer Multisystemanwendung sein.Letztendlich ist Unit Test also das Testen dessen, was Sie als einzelnen Teil eines größeren Systems bezeichnen möchten.

Sie würden dann zum integrierten oder Systemtest übergehen, indem Sie testen, wie alle Komponenten zusammenarbeiten.

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

Ich habe auf der FoxForward 2007 eine Präsentation über Unit-Tests besucht und mir wurde gesagt, ich solle niemals Unit-Tests für irgendetwas durchführen, das mit Daten funktioniert.Denn wenn Sie mit Live-Daten testen, sind die Ergebnisse unvorhersehbar, und wenn Sie nicht mit Live-Daten testen, testen Sie nicht wirklich den Code, den Sie geschrieben haben.Leider ist das der größte Teil der Codierung, die ich heutzutage mache.:-)

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

Ich bin nicht bis zum 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, Sie stecken in einem ständigen Aufräumzustand fest, von dem Sie wissen, dass das Hinzufügen einer neuen Funktion oder eines neuen Codes den aktuellen Satz zerstören kann, weil die aktuelle Software wie ein Haus ist? Karten?

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

Man fängt klein an.Das Projekt, mit dem ich gerade angefangen habe, hatte bis vor ein paar Monaten keine Unit-Tests.Wenn die Abdeckung so gering war, wählten wir einfach eine Datei aus, die keine Abdeckung aufwies, und klickten auf „Tests hinzufügen“.

Im Moment sind wir bei über 40 % angelangt und haben es geschafft, die meisten schwachen Früchte zu ernten.

(Das Beste daran ist, dass wir selbst bei dieser geringen Abdeckung bereits auf viele Instanzen gestoßen sind, in denen der Code das Falsche getan hat, und die Tests haben es erkannt.Das ist eine große Motivation, die Leute dazu zu bewegen, mehr Tests hinzuzufügen.)

Dies ist die Antwort darauf, warum Sie Unit-Tests durchführen sollten.

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

Unit-Test:Jetzt sparen Sie Stunden später – Eric Mann – https://www.youtube.com/watch?v=_UmmaPe8Bzc

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

Testbares JavaScript schreiben - https://www.youtube.com/watch?v=OzjogCFO4Zo

Jetzt lerne ich gerade erst etwas über das Thema, also liege ich vielleicht nicht 100 % richtig 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 Code getrennt gehalten wird). Hauptcode), der eine Funktion in Ihrem Hauptcode mit Eingaben (Argumenten) aufruft, die die Funktion benötigt, und der Code prüft dann, ob er einen gültigen Rückgabewert zurückerhält.Wenn ein gültiger Wert zurückgegeben wird, zeigt das Unit-Testing-Framework, das Sie zum Ausführen der Tests verwenden, ein grünes Licht an (alles in Ordnung). Wenn der Wert ungültig ist, erhalten Sie ein rotes Licht und Sie können das Problem direkt vor Ihnen beheben Geben Sie den neuen Code für die Produktion frei. Ohne Tests ist Ihnen der Fehler möglicherweise nicht aufgefallen.

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 hat oder etwas vollständig zurückgibt anders als das, was diese Funktion zurückgeben soll.Auch hier ist es ohne den Test möglicherweise schwierig, diesen Fehler aufzuspüren, da er sich möglicherweise auch auf anderen Code auswirken kann und unbemerkt bleibt.

Auch die Tatsache, dass Sie über ein Computerprogramm verfügen, das Ihren Code durchläuft und ihn testet, anstatt dass Sie ihn Seite für Seite manuell im Browser ausführen müssen, spart Zeit (Komponententests für Javascript).Nehmen wir an, Sie ändern eine Funktion, die von einem Skript auf einer Webseite verwendet wird, und sie funktioniert für ihren neuen beabsichtigten Zweck einwandfrei.Nehmen wir aber der Argumentation halber auch an, dass Sie an anderer Stelle in Ihrem Code eine andere Funktion haben, deren ordnungsgemäße Funktion von dieser neu geänderten Funktion abhängt.Aufgrund der Änderungen, die Sie an der ersten Funktion vorgenommen haben, funktioniert diese abhängige Funktion jetzt möglicherweise nicht mehr. Ohne Tests, die automatisch von Ihrem Computer ausgeführt werden, werden Sie jedoch erst dann bemerken, dass ein Problem mit dieser Funktion vorliegt, wenn sie tatsächlich ausgeführt wird Sie müssen manuell zu einer Webseite navigieren, die das Skript enthält, das die abhängige Funktion ausführt. Erst dann bemerken Sie, dass aufgrund der Änderung, die Sie an der ersten Funktion vorgenommen haben, ein Fehler vorliegt.

Um es noch einmal zu betonen: Durch die Durchführung von Tests während der Entwicklung Ihrer Anwendung werden diese Art von Problemen beim Codieren erkannt.Ohne die Tests müssten Sie Ihre gesamte Anwendung manuell durchgehen, und selbst dann kann es schwierig sein, den Fehler zu erkennen. Naiverweise schicken 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 Test-Framework).

Es ist ziemlich verwirrend, wenn man zum ersten Mal von dem Thema hört und sich denkt: Teste ich meinen Code nicht schon?Und der Code, den Sie geschrieben haben, funktioniert bereits so, wie er soll. „Warum brauche ich ein anderes Framework?“ ...Ja, Sie testen Ihren Code bereits, aber ein Computer kann das besser.Sie müssen nur einmal ausreichend gute Tests für eine Funktion/Codeeinheit schreiben und der Rest wird von der leistungsstarken CPU für Sie erledigt, anstatt dass Sie manuell überprüfen müssen, ob Ihr gesamter Code noch funktioniert, wenn Sie eine Änderung vornehmen dein Code.

Außerdem müssen Sie Ihren Code nicht einem Unit-Test unterziehen, wenn Sie dies nicht möchten. Dies zahlt sich jedoch aus, da Ihre Projekt-/Codebasis größer wird und die Wahrscheinlichkeit der Einführung von Fehlern zunimmt.

Unit-Tests und TDD im Allgemeinen ermöglichen Ihnen kürzere Feedback-Zyklen zu der Software, die Sie schreiben.Anstatt ganz am Ende der Implementierung eine große Testphase durchzuführen, testen Sie inkrementell alles, was Sie schreiben.Dadurch erhöht sich die Codequalität enorm, da man sofort sieht, wo eventuell Fehler vorhanden sind.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top