Was ist Unit-Tests?

stimmen
193

Ich sah in einer bestimmten Sprache, wie 'zu Unit-Test viele Fragen zu stellen, aber keine Frage zu stellen, ‚was‘, ‚warum‘ und ‚wann‘.

  • Was ist es?
  • Was bedeutet es für mich tun?
  • Warum sollte ich es verwenden?
  • Wann soll ich es verwenden (auch wenn nicht)?
  • Was sind einige häufige Fehler und Missverständnisse
Veröffentlicht am 04/08/2008 um 17:27
quelle vom benutzer
In anderen Sprachen...                            


20 antworten

stimmen
182

Unit-Tests ist, grob gesagt, es testet Bits des Codes in Isolation mit Testcode. Die unmittelbaren Vorteile, die den Sinn kommen, sind:

  • die Tests laufen wird automatisieren-able und wiederholbar
  • Sie können auf einem viel detaillierteren Ebene als Test Point-and-Click-Tests über eine GUI

Beachten Sie, dass, wenn Ihr Code-Test in eine Datei schreibt, Verbindung eine Datenbank öffnet oder tut etwas, über das Netzwerk, ist es besser geeignet als Integrationstest kategorisiert. Integrationstests sind eine gute Sache, sollte aber nicht mit Unit-Tests verwechselt werden. Unit-Test-Code sollte kurz, süß und schnell sein, auszuführen.

Ein anderer Weg, um Unit-Tests zu sehen ist, dass Sie die Tests zuerst schreiben. Dies wird als Testgetriebene Entwicklung (TDD kurz) bekannt. TDD bringt weitere Vorteile:

  • Sie schreiben nicht spekulativ Code „ich dies in Zukunft vielleicht brauchen“ - gerade genug, um die Tests zu machen passieren
  • Der Code, den Sie geschrieben haben, wird immer durch Tests abgedeckt
  • Durch das Schreiben zunächst den Test, sind Sie in das Denken über gezwungen, wie Sie wollen, um den Code zu nennen, die in der Regel das Design des Codes auf lange Sicht verbessert.

Wenn Sie nicht Unit-Tests jetzt tun, empfehle ich Ihnen darauf loszulegen. Holen Sie sich ein gutes Buch, praktisch jedes xUnit-Buch wird tun, weil die Konzepte sehr übertragbar zwischen ihnen.

Manchmal kann das Schreiben von Unit-Tests schmerzhaft sein. Wenn es auf diese Weise erhält, versuchen, jemanden zu finden, Ihnen zu helfen, und die Versuchung widerstehen, „nur das verdammte Code schreiben“. Unit-Tests sind ein viel wie das Geschirr zu waschen. Es ist nicht immer angenehm, aber es hält die metaphorische Küche sauber, und Sie wollen es wirklich sauber sein. :)


Edit: Ein Missverständnis in den Sinn kommt, obwohl ich nicht sicher bin, ob es so üblich ist. Ich habe ein Projekt-Manager gehört sagen, dass Unit-Tests hat das Team zweimal den gesamten Code schreiben. Wenn es sieht aus und fühlt sich auch so, na ja, Sie tun es falsch. Nicht nur, dass das Schreiben in der Regel die Tests auf die Entwicklung beschleunigen, aber es gibt Ihnen auch eine bequeme „jetzt bin ich fertig“ -Anzeige, die Sie sonst nicht hätte.

Beantwortet am 04/08/2008 um 17:36
quelle vom benutzer

stimmen
65

Ich widersprechen nicht mit Dan (obwohl eine bessere Wahl nur sein kann, nicht antworten) ... aber ...

Unit-Tests sind der Prozess, Code zu schreiben, das Verhalten und die Funktionalität des Systems zu testen.

Offensichtlich prüft die Qualität des Codes verbessern, aber das ist nur eine oberflächliche Nutzen von Unit-Tests. Die tatsächlichen Vorteile sind:

  1. Machen Sie es leichter, die technische Umsetzung zu ändern, während dafür, dass Sie nicht das Verhalten ändern (Refactoring). Richtig getestet Einheit Code aggressiv Refactoring / aufgeräumt mit wenig Chancen etwas zu brechen, ohne es merken werden kann.
  2. Gibt Entwickler Vertrauen beim Hinzufügen von Verhalten oder machen Behebungen.
  3. Dokumentieren Sie Ihren Code
  4. Geben Sie Bereiche des Codes, die eng gekoppelt sind. Es ist schwer zu Unit-Test-Code, der eng gekoppelt ist
  5. Bieten Sie eine Möglichkeit Ihre API zu nutzen und frühzeitig auf Schwierigkeiten aussehen
  6. Gibt Methoden und Klassen, die nicht sehr kohäsiv sind

Sie sollten Unit-Test, weil seine in Ihrem Interesse eine wartbare und qualitativ hochwertiges Produkt für Ihre Kunden zu liefern.

Ich würde Sie für jedes System verwenden Sie es vorschlagen, oder Teil eines Systems, die Modelle der realen Welt Verhalten. Mit anderen Worten, es ist besonders gut für die Entwicklung von Unternehmen geeignet. Ich würde es nicht Wegwerf / Dienstprogramme verwenden für. Ich würde es nicht für Teile eines Systems verwenden, die problematisch sind Test (UI ist ein typisches Beispiel, aber das ist nicht immer der Fall ist)

Der größte Nachteil ist , dass die Entwickler testen zu großer Einheit, oder sich als eine Methode einer Einheit. Dies gilt insbesondere , wenn Sie nicht verstehen , Inversion of Control - in diesem Fall der Komponententests werden sich immer in End-to-End - Integrationstests. Unit - Test sollten die einzelnen Verhaltensweisen testen - und die meisten Methoden haben viele Verhaltensweisen.

Das größte Missverständnis ist, dass Programmierer sollten nicht testen. Nur schlechte oder faul Programmierer glauben, dass. Sollte der Typ Ihr ​​Dach bauen nicht testen? Sollte der Arzt eine Herzklappe ersetzt nicht das neue Ventil testen? Es kann nur ein Programmierer testen, dass sein Code tut, was er zu tun gedenke (QA können Grenzfälle testen - wie Code verhält, wenn er erzählt hat, Dinge zu tun, die Programmierer nicht die Absicht, und der Kunde kann Abnahmeprüfung tun - der Code tun was, was bezahlt der Kunde für es zu tun)

Beantwortet am 04/08/2008 um 17:41
quelle vom benutzer

stimmen
40

Der Hauptunterschied der Unit - Tests, im Gegensatz zu „gerade ein neues Projekt zu öffnen und testen Sie diesen spezifischen Code“ ist , dass es automatisiert , so wiederholbar .

Wenn Sie Ihren Code manuell testen, kann es Ihnen davon überzeugen , dass der Code funktioniert einwandfrei - in seinem aktuellen Zustand . Aber was ist eine Woche später, wenn Sie in eine leichte Modifikation gemacht? Sind Sie bereit , es erneut zu testen wieder von Hand , wenn etwas in Ihrem Code ändert? Wahrscheinlich 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 auch die Unit - Tests in automatisierten Build - Prozess integrieren, werden sie Ihnen auf Fehler auch in den Fällen alarmieren , wo ein scheinbar völlig unabhängig Veränderung etwas in einem weit entfernten Teil der Codebasis brach - wenn es nicht einmal zu Ihnen kommen würde , dass es eine Notwendigkeit , dass bestimmte Funktionalität erneut zu testen.

Dies ist der Hauptvorteil von Unit-Tests über Hand-Tests. Aber warten Sie, es ist mehr:

  • Unit - Tests verkürzen die Entwicklungsrückkopplungsschleife dramatisch: mit einer eigenen Abteilung Test es Wochen dauern kann , für Sie zu wissen , dass es einen Fehler im Code ist, durch die Zeit , die Sie haben bereits viel von dem Kontext vergessen, so kann es Ihnen Stunden in Anspruch nehmen finden und die Fehler beheben; Mit Unit - Tests OTOH wird der Feedback - Zyklus in Sekunden gemessen, und der Bug - Fix - Prozess ist in der Regel entlang der Linien eines „oh sh * t, ich habe vergessen , für diese Bedingung zu überprüfen , hier“ :-)
  • Unit - Tests effektiv dokumentieren (Ihr Verständnis) , um das Verhalten des Codes
  • Unit - Tests zwingen Sie Ihre Design - Entscheidungen, die dazu führen , neu zu bewerten einfacher, sauberer Entwurf

Unit-Test-Frameworks, die wiederum macht es einfach für Sie zu schreiben und Ihre Tests zu laufen.

Beantwortet am 14/03/2010 um 18:20
quelle vom benutzer

stimmen
29

Ich war nie Unit-Tests an der Universität lehrte, und es dauerte eine Weile, um „get“ es. Ich habe gelesen, es ging „ah, rechts, automatisierte Tests, so cool sein könnte, ich denke“, und dann vergaß ich es.

Es dauerte eine ganze etwas länger , bevor ich wirklich den Punkt herausgefunden : Lassen Sie uns sagen , dass Sie auf einem großen System arbeiten und Sie schreiben ein kleines Modul. Es kompiliert, können Sie es auf Herz und Nieren, es funktioniert super, Sie auf die nächste Aufgabe bewegen. Neun Monate nach der Zeile und zwei Versionen später jemand anderes macht eine Änderung zu einem gewissen scheinbar nicht verwandten Teil des Programms, und es bricht das Modul. Schlimmer noch, sie testen ihre Änderungen und deren Code funktioniert, aber sie Ihr Modul nicht testen; Hölle, sie können nicht einmal wissen , dass Ihr Modul existiert .

Und jetzt hast du ein Problem: broken Code im Kofferraum ist und noch niemand kennt. Der beste Fall ist ein interner Tester, bevor Sie Schiff findet, aber Code Festsetzung, die im Spiel spät ist teuer. Und wenn kein interner Tester findet es ... na ja, das kann in der Tat sehr teuer werden.

Die Lösung ist Komponententests. Sie werden Probleme fangen , wenn Sie Code schreiben - und das ist gut - aber man konnte das von Hand getan haben. Die eigentliche Auszahlung ist , dass sie Probleme 9 Monate auf der ganzen Linie fangen werden , wenn Sie jetzt auf ein ganz anderes Projekt arbeiten, aber ein Sommer intern denkt , dass es aufgeräumter aussehen werden , wenn diese Parameter in alphabetischer Reihenfolge sind - und dann der Unit - Test Sie schrieb nicht zurück, und jemand wirft Dinge in der intern , bis er die Parameter , um wieder ändert. Das ist die „Warum“ von Unit - Tests. :-)

Beantwortet am 19/09/2008 um 13:45
quelle vom benutzer

stimmen
12

Chipping in die philosophischen Vor der Unit-Tests und TDD hier sind ein paar der sie Schlüssel „Glühbirne“ Beobachtungen, die auf meiner vorläufigen ersten Schritte auf dem Weg fiel mir auf TDD Erleuchtung (keine Original oder notwendigerweise news) ...

  1. TDD bedeutet nicht die doppelte Menge an Code zu schreiben. Testcode ist in der Regel ziemlich schnell und schmerzlos zu schreiben und ist ein wichtiger Teil Ihres Design-Prozesses und kritisch.

  2. TDD hilft Ihnen zu erkennen, bei der Codierung zu stoppen! Ihre Tests gibt Ihnen Vertrauen, die Sie jetzt genug getan haben und stoppen können zwicken und ziehen weiter zum nächsten Punkt.

  3. Die Tests und der Code zusammenarbeiten, um besseren Code zu erreichen. Der Code könnte schlecht / Buggy sein. Ihr Test könnte schlecht / Buggy sein. In TDD setzt man auf die Chancen beider ist schlecht / Buggy ziemlich gering ist. Oft ist es das Test, die Festsetzung muss, aber das ist immer noch ein gutes Ergebnis.

  4. TDD hilft bei Verstopfung Codierung. Sie wissen, dass das Gefühl, dass Sie so viel zu tun haben, wissen Sie kaum, wo anfangen? Es ist Freitagnachmittag, wenn Sie nur für ein paar Stunden verschleppen ... TDD ermöglicht es Ihnen, sehr schnell zu konkretisieren, was Sie denken, Sie tun müssen, und bekommt Ihr schnell Codierung zu bewegen. Auch, wie Laborratten, ich denke, wir alle auf das große grüne Licht reagieren und härter arbeiten, es wieder zu sehen!

  5. In ähnlicher Weise können diese Designer-Typen sehen, was sie gerade arbeiten. Sie können für eine Saft / Zigarette / iphone Pause wandern aus und kehren Sie zu einem Monitor, der sofort gibt ihnen einen visuellen Hinweis, wo sie hin ist. TDD gibt uns etwas Ähnliches. Es ist einfacher zu sehen, wo wir bekamen, wenn das Leben greift ...

  6. Ich glaube, es war Fowler, der sagte: „Imperfect Tests laufen häufig, sind viel besser als perfekt Tests, die überhaupt nicht geschrieben werden“. Ich interprete dies als ich Erlaubnis gebend, Tests zu schreiben, wo ich denke, dass sie sehr nützlich sein, auch wenn der Rest meines Code Coverage woefully unvollständig ist.

  7. TDD hilft in allen Arten von überraschender Weise auf der ganzen Linie. Gute Unit-Tests können Dokument helfen, was etwas tun soll, können sie Ihnen helfen, Code von einem Projekt zum anderen wandern und geben Ihnen eine unberechtigte Gefühl der Überlegenheit über Ihre Nicht-Prüfung Kollegen :)

Diese Präsentation ist eine hervorragende Einführung in allen yummy Güte Tests zur Folge hat .

Beantwortet am 24/08/2008 um 22:58
quelle vom benutzer

stimmen
7

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

Beantwortet am 14/03/2010 um 19:10
quelle vom benutzer

stimmen
5

Ich benutze Unit-Tests, Zeit zu sparen.

Wenn die Geschäftslogik Aufbau (oder Datenzugriff) Testfunktionalität oft kann es sich um Sachen in eine Menge von Bildschirmen eingeben, der noch nicht abgeschlossen werden kann oder nicht. diese Tests die Automatisierung spart Zeit.

Für mich sind Unit-Tests eine Art modularisierten Testumgebung. Es ist in der Regel mindestens ein Test pro öffentlicher Funktion. Ich schreibe zusätzliche Tests verschiedene Verhaltensweisen zu decken.

Alle Sonderfälle, die Sie daran gedacht, bei der Entwicklung von Code in dem Code in den Unit-Tests aufgezeichnet werden. Die Unit-Tests werden auch eine Quelle der Beispiele, wie Sie den Code verwenden.

Es ist viel schneller für mich zu entdecken, dass mein neuen Code etwas in meinen Unit-Tests bricht dann in dem Code zu überprüfen und haben einig Front-End-Entwickler ein Problem finden.

Für den Datenzugriff Tests versuche ich Tests zu schreiben, die entweder keine Veränderung oder nach selbst aufzuräumen.

Unit-Tests werden in der Lage sein, nicht alle Testanforderungen zu lösen. Sie werden in der Lage, Entwicklungszeit und Testkernteile der Anwendung zu speichern.

Beantwortet am 17/09/2008 um 01:38
quelle vom benutzer

stimmen
5

Dies ist mein nehmen auf sie. Ich würde sagen , Unit - Tests sind die Praxis - Software - Tests zu schreiben , um zu überprüfen , dass Ihre wirkliche Software tut , was es soll. Dies begann mit jUnit in der Java - Welt und hat eine bewährte Methode in PHP als auch mit mir Simple und PHPUnit . Es ist eine Kern Praxis der Extreme Programming und helfen Ihnen , sicher zu sein , dass Ihre Software nach wie vor als nach der Bearbeitung vorgesehen funktioniert. Wenn Sie eine ausreichende Testabdeckung haben, können Sie großen Refactoring, Bugfixing tun oder neue Funktionen schnell mit viel weniger Angst vor der Einführung von anderen Problemen.

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

Unit-Tests werden in der Regel mit OO Entwicklung verbunden. Die Grundidee ist es, ein Skript zu erstellen, die für Ihren Code auf die Umwelt setzt und dann übt sie; Sie schreiben Behauptungen, die beabsichtigte Ausgabe an, die Sie erhalten sollen und dann Testskript ausführen, um einen Rahmen, wie diejenigen, unter Verwendung der oben genannten.

In diesem Rahmen werden alle Tests gegen Ihren Code ausführen und dann Erfolg oder Misserfolg eines jeden Tests berichten. PHPUnit wird von der Linux-Befehlszeile standardmäßig ausgeführt, obwohl es für sie HTTP-Schnittstellen zur Verfügung steht. Simple webbasiert ist von Natur aus und ist viel einfacher zu bekommen und läuft, IMO. In Kombination mit xDebug, PHPUnit können Sie automatisierte Statistiken für Codeabdeckung geben, die einige Leute sehr nützlich finden.

Einige Teams schreiben Haken aus ihrer Subversion-Repository, so dass Unit-Tests automatisch gestartet werden, wenn Sie Änderungen.

Es ist gut, Praxis Ihrer Unit-Tests in der gleichen Repository wie Ihre Anwendung zu halten.

Beantwortet am 05/08/2008 um 00:53
quelle vom benutzer

stimmen
4

Bibliotheken wie NUnit , xUnit oder JUnit sind nur erforderlich , wenn Sie Ihre Projekte mit dem entwickeln wollen TDD Ansatz von Kent Beck populär gemacht :

Sie können lesen , Einführung in Test Driven Development (TDD) oder Kent Becks Buch By Example: Test Driven Development .

Dann, wenn Sie Ihre Tests einen „guten“ Teil des Codes decken sicher sein wollen, können Sie Software wie verwenden NCover , JCover , Partcover oder was auch immer. Sie werden Ihnen sagen, die Berichterstattung Prozentsatz Ihres Codes. Je nachdem , wie viel Sie bei TDD geschickt sind, werden Sie wissen , wenn Sie es gut genug geübt haben :)

Beantwortet am 14/03/2010 um 18:22
quelle vom benutzer

stimmen
3

Ich denke , der Punkt , dass Sie nicht verstehen ist , dass Einheit Test - Frameworks wie NUnit (und dergleichen) werden Ihnen helfen , in der Automatisierung von kleinen bis mittelgroßen Tests. Normalerweise können Sie die Tests in einer GUI laufen (das ist der Fall mit NUnit , zum Beispiel) , indem Sie einfach auf einen Knopf klicken und dann - hoffentlich - siehe die Statusleiste grün bleiben. Wenn es rot wird, zeigt das Framework Sie die Prüfung nicht bestanden und was genau schief gelaufen ist . In einem normalen Gerät zu testen, verwenden Sie oft Behauptungen, zum Beispiel Assert.AreEqual(expectedValue, actualValue, "some description")- also wenn die beiden Werte ungleich sind , werden Sie eine Fehlermeldung , dass „eine Beschreibung: erwartete <expectedValue> aber war <actual>“ sehen.

So wie eine Schlussfolgerung Testeinheit macht die Prüfung schneller und viel bequemer für Entwickler. Sie können alle Unit-Tests ausführen, bevor neuer Code zu begehen, so dass Sie nicht über den Build-Prozess von anderen Entwicklern auf dem gleichen Projekt brechen.

Beantwortet am 14/03/2010 um 18:25
quelle vom benutzer

stimmen
3

Unit-Tests sind eine Praxis, um sicherzustellen, dass die Funktion oder ein Modul, das Sie implementieren gehen wird wie erwartet (Anforderungen) verhalten und auch sicher zu machen, wie es in Szenarien wie Randbedingungen verhält und ungültige Eingabe.

xUnit , NUnit , MbUnit etc. sind Werkzeuge , die Sie beim Schreiben der Tests helfen.

Beantwortet am 14/03/2010 um 18:22
quelle vom benutzer

stimmen
3

Unit-Tests sind über das Schreiben von Code, den Anwendungscode prüft.

Die Einheit eines Teil des Namen ist über die Absicht kleine Einheiten von Code (eine Methode , zum Beispiel) zu testen , zu einer Zeit.

xUnit ist es mit diesem Test zu helfen - sie sind Rahmenbedingungen, die dabei behilflich sein. Ein Teil davon ist Testläufer automatisiert, die Ihnen sagen, welche Test nicht bestehen und welche passieren.

Sie haben auch Einrichtungen zur Einrichtung gemeinsamer Code, den Sie in jedem Test, bevor die Hand benötigen, und reißen es ab, wenn alle Tests abgeschlossen haben.

Sie können einen Test zu überprüfen, ob eine erwartete Ausnahme ausgelöst wurde, ohne dass die ganze try catch-Block selbst zu schreiben.

Beantwortet am 14/03/2010 um 18:19
quelle vom benutzer

stimmen
3

Verwenden Sie Testivus . Alles , was Sie wissen müssen, ist genau dort :)

Beantwortet am 17/09/2008 um 01:48
quelle vom benutzer

stimmen
2

Zunächst einmal, ob über Unit-Tests sprechen oder irgendwelche andere Arten von automatisierten Tests (Integration, Last, UI-Tests etc.), der wesentliche Unterschied von dem, was Sie vorschlagen, ist, dass es automatisiert ist, wiederholbar und es erfordert kein Personal verzehrt werden (hat = niemand die Tests durchzuführen, bei einem Knopfdruck laufen sie in der Regel).

Beantwortet am 14/03/2010 um 18:22
quelle vom benutzer

stimmen
2

Test Driven Development hat Art über die Laufzeit Einheit Test genommen. Als alter Timer werde ich die allgemeinere Definition davon erwähnen.

Einheit Test bedeutet auch eine einzelne Komponente in einem größeren System zu testen. Diese einzelne Komponente könnte eine dll, exe, Klassenbibliothek sein usw. Es könnte auch nur ein einziges System in einer Multi-System-Anwendung sein. So sind letztlich Unit Test endet als die Prüfung, was Sie wollen ein einzelnes Stück eines größeren Systems nennen.

Sie würden dann auf integrierte oder Systemtests nach oben durch die Prüfung, wie alle Komponenten zusammenarbeiten.

Beantwortet am 24/08/2008 um 23:34
quelle vom benutzer

stimmen
2

Unit-Testing ist die Prüfung einer Codeeinheit (zB eine einzelne Funktion), ohne die Notwendigkeit für die Infrastruktur, die die Einheit von Code stützt sich auf. dh es testen isoliert.

Wenn zum Beispiel, dass die Funktion, die Sie testen sind mit einer Datenbank verbindet und macht ein Update, in einem Unit-Test können Sie nicht das Update machen wollen. Sie würden wenn es ein Integrationstest, aber in diesem Fall ist es nicht.

So wäre ein Unit-Test die Funktionalität in der „Funktion“ eingeschlossen üben Sie testen, ohne Nebenwirkungen der Datenbank zu aktualisieren.

Sagen Sie Ihre Funktion einiger Zahlen aus einer Datenbank abgerufen und durchgeführt, um eine Standardabweichung Berechnung. Was wollen Sie hier testen? Dass die Standardabweichung berechnet wird, richtig oder dass die Daten aus der Datenbank zurückgegeben werden?

In einem Unit-Test wollen Sie nur testen, dass die Standardabweichung korrekt berechnet wird. In einem Integrationstest möchten Sie die Standardabweichung Berechnung und die Datenbankabfrage testen.

Beantwortet am 15/08/2008 um 18:42
quelle vom benutzer

stimmen
1

Dies beantwortet, warum sollten Sie Unit-Tests tun.


Die 3 Videos unter der Abdeckung Unit-Tests in Javascript, aber die allgemeinen Grundsätze gelten in den meisten Sprachen.

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

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

Schreiben Prüfbar JavaScript - https://www.youtube.com/watch?v=OzjogCFO4Zo


Jetzt bin ich nur zu lernen, über das Thema, so kann ich nicht 100% richtig sein, und es gibt mehr zu bieten als das, was ich beschreibe hier, aber mein grundlegendes Verständnis der Unit-Tests ist, dass Sie einige Testcode schreiben (die von getrennt gehalten wird Ihre Hauptcode), die mit Eingang (Argumente), dass die Funktion erfordert und der Code überprüft dann eine Funktion in der Haupt-Code ruft, wenn es einen gültigen Rückgabewert zurückkommt. Wenn es den Komponententestframework gültigen Wert zurück, die Sie verwenden die Tests ausführen zeigt ein grünes Licht (alle gut), wenn der Wert ungültig ist ein rotes Licht leuchtet und Sie können dann das Problem sofort beheben, bevor Sie lassen Sie den neuen Code zu Produktion, ohne Prüfung der Fehler möglicherweise tatsächlich nicht gefangen.

So schreiben Sie Tests für aktuellen Code, den Sie und den Code erstellen, so dass er den Test besteht. Monate später Sie oder jemand andere Notwendigkeit, die Funktion in Ihrem Haupt-Code zu ändern, denn zuvor hatte man bereits geschrieben Test-Code für diese Funktion jetzt Sie wieder laufen und der Test fehlschlagen, weil der Codierer vollständig einen Logikfehler in der Funktion oder Rückkehr etwas eingeführt anders als das, was diese Funktion zurückkehren soll. Wieder ohne den Test anstelle könnten, dass Fehler schwer aufzuspüren, da es möglicherweise auch andere Codes und unbemerkt gehen beeinflussen können.


Auch die Tatsache, dass Sie ein Computer-Programm, das durch den Code ausgeführt wird und testet es anstelle von Ihnen manuell im Browser Seite für Seite zu tun spart Zeit (Unit-Tests für JavaScript). Lassen Sie uns sagen, dass Sie eine Funktion ändern, die durch ein Skript auf einer Webseite verwendet wird, und es funktioniert alles gut und gut für den neuen Verwendungszweck. Aber lassen Sie sich auch für Argumente willen sagen, dass es eine andere Funktion, die Sie woanders in Ihrem Code haben, der auf die neu modifizierte Funktion hängt es richtig zu funktionieren. Diese abhängige Funktion kann jetzt aufhören zu arbeiten, weil die Änderungen, die Sie auf die ersten Funktion vorgenommen haben, jedoch ohne Prüfungen an Ort und Stelle, die automatisch von Ihrem Computer ausgeführt wird, werden Sie nicht feststellen, dass es ein Problem mit dieser Funktion, bis sie tatsächlich ausgeführt werden und Sie'

Um es zu wiederholen, mit Tests, die ausgeführt werden, während der Entwicklung Ihre Anwendung wird diese Art von Problemen fangen, wie Sie Codierung. Nicht mit den Tests in Ort, den Sie manuell Ihre gesamte Anwendung haben würden gehen und selbst dann kann es schwierig sein, den Fehler zu erkennen, Sie naiv es in der Produktion schicken und nach einer Weile eine Art Benutzer senden Ihnen einen Fehlerbericht (die nicht so gut wie Ihre Fehlermeldungen in einer Test-Framework) sein.


Es ist ziemlich verwirrend, wenn Sie zuerst hören des Themas und Sie sich selbst denken, bin ich nicht schon meinen Code testen? Und der Code, den Sie geschrieben haben, funktioniert wie es soll bereits, „warum muss ich einen anderen Rahmen brauchen?“ ... Ja, Sie bereits Ihren Code testen, aber ein Computer ist besser, es zu tun. Sie müssen nur einmal gut genug, um Tests für eine Funktion / Einheit Code schreiben, und der Rest wird von dem mächtigen CPU für Sie gesorgt statt manuell mit überprüfen, ob alle Ihren Code noch funktionieren, wenn Sie eine Änderung vornehmen zu dein Code.

Auch Sie haben nicht zu Einheit testen Sie den Code, wenn Sie nicht wollen, aber es lohnt sich, wie Ihr Projekt / Code-Basis aus beginnt zu wachsen größer als die Chancen von Fehlern erhöht einzuführen.

Beantwortet am 18/07/2015 um 18:34
quelle vom benutzer

stimmen
1

Was tun Sie, wenn Sie einen Haufen Mist gegeben sind und scheinen, wie Sie in einem ständigen Zustand der Bereinigung stecken, die Sie mit dem Zusatz einer neuen Funktion oder Code kennt, kann den aktuellen Satz brechen, da die aktuelle Software wie ein Haus ist von Karten?

Wie können wir Unit-Tests dann tun?

Sie fangen klein an. Das Projekt, das ich habe gerade in hatte keine Unit-Tests, bis vor ein paar Monaten. Wenn Abdeckung dass niedrig war, würden wir einfach eine Datei auswählen, die keine Deckung hatte und klicken Sie auf „Tests hinzufügen“.

Im Moment sind wir bis zu mehr als 40%, und wir haben es geschafft, den größten Teil der niedrig hängenden Früchte zu pflücken.

(Der beste Teil ist, dass selbst bei dieser geringen Höhe der Deckung, haben wir bereits in vielen Fällen der Code ausführen, das Falsche zu tun, und die Prüfung fing es. Das ist ein großer Motivator Menschen zu schieben mehr Tests hinzuzufügen.)

Beantwortet am 22/08/2008 um 19:19
quelle vom benutzer

stimmen
1

Ich ging zu einem Vortrag über Unit-Tests bei FoxForward 2007 und wurde nie zu Unit-Test etwas erzählt, die mit Daten arbeitet. Nach allem, wenn Sie auf Live-Daten zu testen, sind die Ergebnisse nicht vorhersehbar, und wenn Sie nicht auf Live-Daten testen Sie, dass Sie nicht wirklich testen Sie den Code geschrieben haben. Leider ist das die meisten der Codierung ich in diesen Tagen tun. :-)

Ich habe vor kurzem einen Schuss auf TDD nehmen, wenn ich eine Routine zu schreiben Einstellungen zu speichern und wiederherzustellen. Zuerst habe ich festgestellt, dass ich das Speicherobjekt erstellen können. Dann, sie habe die Methode, die ich nennen musste. Dann, dass ich konnte es nennen. Dann, dass ich passieren könnte es Parameter. Dann, dass ich es bestimmte Parameter übergeben kann. Und so weiter, bis ich schließlich überprüfen, ob es die angegebene Einstellung speichern würde, erlauben Sie mir, es zu ändern, und dann wiederherstellen, für mehrere verschiedene Syntaxen.

Ich habe nicht bis zum Ende zu erhalten, da ich brauchte the Routine-jetzt-dammit, aber es war eine gute Übung.

Beantwortet am 22/08/2008 um 19:10
quelle vom benutzer

stimmen
0

Unit-Testing und TDD im allgemeinen können Sie kürzeren Feedbackzyklen über die Software haben Sie schreiben. Statt eine große Testphase am Ende der Umsetzung ist, testen Sie schrittweise alles, was Sie schreiben. Dies erhöht die Qualität des Codes sehr viel, wie Sie sofort sehen, wo Sie Fehler haben könnten.

Beantwortet am 03/05/2017 um 09:33
quelle vom benutzer

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more