TDD - Anfänger Probleme und Stolpersteine

Question

Während ich Unit-Tests geschrieben habe für die meisten der Code, den ich gemacht habe, habe ich erst vor kurzem meine Hände auf einer Kopie von TDD mit gutem Beispiel von Kent Beck bekam. Ich habe immer bestimmte Design-Entscheidungen bedauert ich gemacht, da sie die Anwendung von Seinem ‚prüfbar‘ verhindert. Ich las das Buch durch und während einige davon fremd aussieht, fühlte ich, dass ich es schaffen könnte und beschlossen, es auf meinem aktuellen Projekt auszuprobieren, die im Grunde ein Client / Server-System, wo die beiden Teile über kommunizieren. USB. Ein auf dem Gerät und der andere auf dem Host. Die Anwendung ist in Python.

begann ich ab und schon bald bekam in einem Gewirr von Neufassungen und winzigen Tests verstrickt, die später dachte ich tat Test nicht wirklich etwas. Ich warf die meisten von ihnen und und jetzt eine funktionierende Anwendung haben, für die die Tests in allen geronnen nur 2

Auf der Grundlage meiner Erfahrungen, habe ich ein paar Fragen, die Ich mag würde fragen. Ich gewann einige Informationen von Neu bei TDD: gibt es Beispielanwendungen mit Tests zu zeigen, wie TDD zu tun aber einige spezifische Fragen haben, die ich Antworten auf / Diskussion möchten?.

1. verwendet Kent Beck eine Liste, die er ergänzt und streicht von dem Entwicklungsprozess zu führen. Wie kann man eine solche Liste zu machen? Ich hatte zunächst ein paar Dinge wie „Server starten sollte“, „Server abbrechen soll, wenn Kanal nicht verfügbar ist“ etc., aber sie bekamen gemischt und schließlich jetzt, es ist nur so etwas wie „Client sollte mit dem Server verbinden kann“ (die subsumiert Serverstart usw.).
2. Wie gehen Sie umschreibt? Ich zunächst ein Halbduplex-System, basierend auf Named Pipes ausgewählt, so dass ich die Anwendungslogik auf meinem eigenen Rechner entwickeln könnte und dann den USB-Kommunikationsteil später hinzufügen. Es bewegte sie eine Sockets Sache zu werden, und dann verwenden, Raw Sockets zur Verwendung der Python-Modul Socket bewegte. Jedes Mal, die Dinge geändert, ich fand, dass ich erhebliche Teile der Tests neu zu schreiben hatte was ärgerlich war. Ich habe gedacht, dass die Tests eine etwas unveränderliche Führung während meiner Entwicklung sein würden. Sie wie mehr Code Griff fühlen.
3. musste ein Client und einem Server, den Kanal zu kommunizieren durch jede Seite zu testen. Ich konnte eine der Seiten verspotten, den anderes zu testen, aber dann der ganze Kanal nicht getestet werden, und ich mache mir Sorgen, dass ich das vermissen würde. Dies schmälerte den ganzen rot / grün / refactor Rhythmus. Ist das fehlt nur Erfahrung oder bin ich etwas falsch zu machen?
4. Die „Fake it, bis du es“ mich mit viel unordentlich Code gelassen, dass ich später viel Zeit zu refactor verbracht und aufzuräumen. Ist dies die Art und Weise der Dinge funktionieren?
5. Am Ende der Sitzung, habe ich jetzt meinen Client und Server mit rund 3 oder 4 Unit-Tests ausgeführt habe. Es dauerte etwa eine Woche, es zu tun. Ich glaube, ich es an einem Tag getan haben könnte, wenn ich die Unit-Tests nach dem Code Art und Weise verwendet hat. Ich kann nicht die Verstärkung zu sehen.

Ich suche Kommentare und Ratschläge von Leuten, die ganz große, nicht triviale Projekte umgesetzt haben (oder fast vollständig) mit dieser Methode. Es macht Sinn, mir den Weg zu folgen nach Ich habe schon etwas laufen und wollen eine neue Funktion hinzuzufügen, aber es von Grund auf neu zu tun scheint zu ermüdend und nicht die Mühe wert.

P. S. . Bitte lassen Sie mich wissen, ob diese Community Wiki werden soll, und ich werde es so markiert

Update 0 : Alle Antworten waren ebenso hilfreich. Ich nahm die, die ich tat, weil es mit meinen Erfahrungen der Resonanz.

Update 1 : Praxis Praxis Praxis

Answer 1

Als Vorbemerkung, nimmt TDD Praxis. Wenn ich die Tests zurückblicken ich geschrieben, als ich TDD begann, sehe ich viele Fragen, so wie wenn ich Code sehe ich vor ein paar Jahren schrieb. Halten Sie es zu tun, und wie Sie beginnen guten Code von schlecht zu erkennen, werden die gleichen Dinge passieren mit Ihren Tests - mit Geduld.

  

Wie macht man eine solche Liste? ich   zunächst hatte ein paar Dinge wie „Server   Start-up sollte "" Server sollte abbrechen   wenn der Kanal ist nicht verfügbar“usw., aber   sie bekommt gemischt und schließlich jetzt, es ist   nur so etwas wie „Kunde sollte sein   Lage Server "

verbinden

„Die Liste“ kann eher informell sein (dh der Fall, in Becks Buch ist), aber wenn man in der Herstellung der Produkte in Tests bewegen, versuchen, die Aussagen in einem „zu schreiben [Wenn etwas in diesem Fall] und dann [Dieser Zustand sollte wahr an diesem]“Format. Dieser wird Sie zwingen, mehr darüber nachzudenken, was es ist, Sie zu überprüfen, wie Sie es überprüfen würde und führt direkt zu Tests - oder wenn sie es nicht sollten Sie einen Anhaltspunkt geben, um welche Stück Funktionalität fehlt. Denken Sie Use Case / Szenario. Zum Beispiel „Server starten soll“ ist unklar, weil niemand eine Aktion initiiert.

  

Jedes Mal, die Dinge geändert, fand ich, dass   Ich musste neu zu schreiben erhebliche Teile   Die Tests, die ärgerlich war. Ich würde   dachte, dass die Tests a wären   etwas unveränderliche Führung während meiner   Entwicklung. Sie fühlten sich wie mehr   Code Handle.

Zuerst ja, sind Tests mehr Code und Wartung erfordert - und wartbar Schreiben von Tests erfordert einige Übung. Ich stimme mit S. Lott, wenn Sie Ihre Tests viel ändern müssen, werden Sie wahrscheinlich „zu tief“ zu testen. Im Idealfall möchten Sie auf der Ebene der öffentlichen Schnittstelle testen, die wahrscheinlich nicht zu ändern ist, und nicht auf der Ebene der Umsetzung Details, die sich entwickeln könnten. Aber ein Teil der Übung ist es etwa mit einem Design kommen, so sollten Sie erwarten, falsch einen Teil davon zu bekommen und müssen die Tests als auch bewegen / Refactoring.

  

konnte ich eine der Seiten zu Test verspotten   die andere, aber dann ist der ganze Kanal   würde nicht getestet und ich Sorge, dass   Ich würde das entgehen lassen.

Nicht ganz sicher, dass ein. Aus dem Sausen, ein Modell mit war die richtige Idee: eine Seite nehmen, die andere spotten, und prüfen Sie, dass jede Seite funktioniert, die andere unter der Annahme richtig umgesetzt wird. das ganze System zu testen gemeinsam ist Integrationstests, die Sie auch tun wollen, aber in der Regel nicht Teil des TDD-Prozesses.

  

Das „Fake it, bis du es“ mich verlassen   mit viel unordentlich Code, dass ich später   eine Menge Zeit in Anspruch refactor verbracht und   Aufräumen. Ist dies die Art und Weise der Dinge funktionieren?

Sie sollten viel Zeit verbringen, während Refactoring TDD tun. Auf der anderen Seite, wenn Sie fälschen, ist es vorübergehend und Ihr unmittelbarer nächster Schritt sollte un-fälschen sein. Normalerweise sollten Sie nicht mehr Tests haben vorbei, weil Sie es gefälscht -. Sie sollten zu einem Zeitpunkt auf einem Stück konzentrieren, und die Arbeit an es so schnell wie möglich Refactoring

  

ich glaube, ich es an einem Tag getan haben könnte   wenn ich wurde unter Verwendung der Unit-Tests nach   Code Art und Weise. Ich kann nicht die Verstärkung sehen.

Auch hier dauert es Praxis, und Sie sollen schneller im Laufe der Zeit. Auch, manchmal ist TDD fruchtbarer als andere, ich, dass in einigen Situationen zu finden, wenn ich weiß genau den Code, den ich schreiben will, es ist nur schneller einen guten Teil des Codes zu schreiben, und dann Schreibtests.
Neben Beck, genossen ein Buch, das ich ist The Art of Unit Testing, von Roy Osherove. Es ist kein TDD Buch, und es ist .Net-orientiert, aber Sie könnten wollen es trotzdem einen Blick geben: ein guter Teil darüber, wie wartbare Tests zu schreiben, prüft die Qualität und damit verbundene Fragen. Ich fand, dass das Buch mit meiner Erfahrung hallte nach schriftlichen Prüfungen mit und manchmal kämpfte es richtig zu machen ...
Also mein Rat ist, nicht werfen die towel zu schnell, und es einige Zeit geben. Vielleicht möchten Sie es auch leichter, einen Schuss auf etwas geben - Server-Kommunikation im Zusammenhang Dinge testen klingt nicht wie das einfachste Projekt mit zu beginnen

Answer 2

  

  
1. Kent Beck verwendet eine Liste ... nun endlich, es ist nur so etwas wie „Kunde sollte in der Lage sein, mit dem Server verbinden“ (der Server subsumiert Inbetriebnahme usw.).
  

Oft ist eine schlechte Praxis.

Separate Tests für jede einzelne Schicht der Architektur sind gut.

Konzern Tests neigen dazu, Fragen der Architektur zu verschleiern.

Allerdings testet nur die öffentlichen Funktionen. Nicht jede Funktion.

Und nicht zu viel Zeit zu optimieren Ihre Tests investieren. Redundanz in den Tests nicht so viel schaden, wie es in der Arbeits Anwendung tut. Wenn sich die Dinge ändern und ein Test funktioniert, aber ein anderer Test bricht, dann vielleicht können Sie Ihre Tests Refactoring. Nicht vor.

  

2. Wie gehen Sie umschreibt? ... Ich fand, dass ich erhebliche Teile der Tests.

neu zu schreiben hatte

Sie testen bei zu niedriger Detailstufe. Testen Sie die äußerste, öffentlich sichtbare Schnittstelle. Der Teil, der sein unveränderlich angenommen hat.

Und

Ja, bedeutende architektonische Änderungsmittel signifikante Tests zu ändern.

Und

Der Testcode ist, wie Sie beweisen die Dinge funktionieren. Es ist fast so wichtig wie die Anwendung selber. Ja, es ist mehr Code. Ja, Sie müssen es schaffen.

  

3. Ich brauchte einen Client und einen Server über den Kanal zu kommunizieren, zu beiden Seiten zu testen. Ich konnte eine der Seiten verspotten, den anderen zu testen, aber dann den ganzen Kanal würde nicht getestet werden ...

Es gibt Unit-Tests. Mit Mocks.

Es gibt Integrationstests, die die ganze Sache prüfen.

Verwechseln Sie sie nicht.

Sie können Unit-Test-Tools verwenden, Integrationstests zu tun, aber sie sind verschiedene Dinge.

Und Sie brauchen beides zu tun.

  

4. Der „Fake it till you make it“ hat mich mit viel unordentlich Code, dass ich später viel Zeit zu Refactoring und Sanierung ausgegeben. Ist dies die Art und Weise der Dinge funktionieren?

Ja. Das ist genau, wie es funktioniert. Auf lange Sicht, einige Leute finden diese effektiver als ihr Gehirn zu belasten versuchen, alle Design vorne zu tun. Manche Menschen tun nicht so und wollen alle das Design vorne tun; Du bist frei, viel Design vorne zu tun, wenn Sie wollen.

Ich habe festgestellt, dass Refactoring ist eine gute Sache und Front-Design bis zu hart ist. Vielleicht, weil es Ich habe seit fast 40 Jahren wurde Codierung und mein Gehirn trägt aus.

  

5. Ich kann nicht die Verstärkung sehen.

Alle wahren Genies finden, dass die Prüfung verlangsamt sie.

Der Rest von uns kann nicht sein sicher unser Code funktioniert, bis wir eine komplette Reihe von Tests haben, dass beweisen , dass es funktioniert.

Wenn Sie nicht brauchen Beweis , dass Ihr Code funktioniert, Sie Tests nicht benötigen.

Answer 3

  

Q. Kent Beck verwendet eine Liste, die er ergänzt und streicht von dem Entwicklungsprozess zu führen. Wie kann man eine solche Liste zu machen? Ich hatte zunächst ein paar Dinge wie „Server starten sollte“, „Server abbrechen soll, wenn Kanal nicht verfügbar ist“ etc., aber sie bekamen gemischt und schließlich jetzt, es ist nur so etwas wie „Client sollte mit dem Server verbinden kann“ (die subsumiert Serverstart usw.).

Ich beginne mit etwas Kommissionierung ich überprüfen könnte. In Ihrem Beispiel haben Sie sich „Server starten“.

Server starts

Jetzt sehe ich für jeden einfacher Test, den ich schreiben wollen könnte. Etwas mit weniger Variation und weniger beweglichen Teilen. Ich könnte „konfigurierten Server richtig“, zum Beispiel.

Configured server correctly
Server starts

Wirklich, obwohl "Server startet" abhängig von "konfigurierten Server richtig", so dass ich diese Verbindung deutlich zu machen.

Configured server correctly
Server starts if configured correctly

Nun suche ich Variationen. Ich frage: „Was könnte schief gehen?“ Ich konnte den Server nicht ordnungsgemäß konfiguriert werden. Wie viele verschiedene Möglichkeiten, die Materie? Jede dieser macht einen Test. Wie könnte der Server nicht einmal starten, obwohl ich es richtig konfiguriert? Jeder Fall das macht einen Test.

  

Q. Wie gehen Sie umschreibt? Ich zunächst ein Halbduplex-System, basierend auf Named Pipes ausgewählt, so dass ich die Anwendungslogik auf meinem eigenen Rechner entwickeln könnte und dann den USB-Kommunikationsteil später hinzufügen. Es bewegte sie eine Sockets Sache zu werden, und dann verwenden, Raw Sockets zur Verwendung der Python-Modul Socket bewegte. Jedes Mal, die Dinge geändert, ich fand, dass ich erhebliche Teile der Tests neu zu schreiben hatte was ärgerlich war. Ich habe gedacht, dass die Tests eine etwas unveränderliche Führung während meiner Entwicklung sein würden. Sie fühlen sich wie mehr Code zu behandeln.

Wenn ich Verhalten ändern, finde ich es sinnvoll, die Tests zu ändern, und auch sie zuerst ändern! Wenn ich auf Wechseltests habe, die nicht direkt das Verhalten prüfen ich in dem Prozess bin zu ändern, obwohl, das ein Zeichen ist, dass meine Tests auf zu vielen verschiedenen Verhaltensweisen abhängen. Das sind Integrationstests, die ich denke, sind ein Betrug. (Google "Integrationstests sind ein Betrug")

  

Q. Ich brauchte einen Client und einen Server über den Kanal zu kommunizieren, zu beiden Seiten zu testen. Ich konnte eine der Seiten verspotten, den anderes zu testen, aber dann der ganze Kanal nicht getestet werden, und ich mache mir Sorgen, dass ich das vermissen würde. Dies schmälerte den ganzen rot / grün / refactor Rhythmus. Ist das fehlt nur Erfahrung oder bin ich etwas falsch zu machen?

Wenn ich einen Client, einen Server zu bauen, und einen Kanal, dann versuche ich jede einzeln zu überprüfen. Ich beginne mit dem Kunden, und wenn ich Testfahrt es, ich entscheiden, wie der Server und Kanal Notwendigkeit zu verhalten. Dann implementieren ich den Kanal und Server jeweils das Verhalten anzupassen ich brauche. Wenn die Client-Überprüfung Stummel I den Kanal; wenn der Server überprüft, mock ich den Kanal; Wenn die Kanalprüfung, I Stummel und sowohl Client- als auch Server-Mock. Ich hoffe, das für Sie Sinn macht, da ich einige ernsten Annahmen über die Natur dieses Client, Server und Kanal machen.

  

Q. Der „Fake it till you make it“ hat mich mit viel unordentlich Code, dass ich später viel Zeit zu Refactoring und Sanierung ausgegeben. Ist dies die Art und Weise der Dinge funktionieren?

Wenn Sie Ihren „fake it“ lassen Code sehr chaotisch, bevor es aufräumen, dann haben Sie vielleicht zu lange es fälschen. Das heißt, ich feststellen, dass, obwohl ich mehr Code mit TDD Aufräumen am Ende der Gesamt Rhythmus fühlt sich viel besser. Dies ergibt sich aus der Praxis.

  

Q. Am Ende der Sitzung, ich habe jetzt meinen Client und Server mit rund 3 oder 4 Unit-Tests ausgeführt werden. Es dauerte etwa eine Woche, es zu tun. Ich glaube, ich es an einem Tag getan haben könnte, wenn ich die Unit-Tests nach dem Code Art und Weise verwendet hat. Ich kann nicht die Verstärkung sehen.

Ich muss sagen, dass, wenn Ihr Client und Server sind sehr, sehr einfach, Sie brauchen mehr als 3 oder 4 Tests jeweilszu überprüfen, sie gründlich. Ich denke, dass die Tests überprüfen (oder zumindest execute) eine Reihe von verschiedenen Verhaltensweisen auf einmal, und das könnte Konto für die Mühe, die es Ihnen, sie zu schreiben haben.

Auch nicht die Lernkurve nicht messen. Meine erste echte TDD Erfahrung bestand aus Umschreiben von 3 Monaten im Wert von Arbeit in 9, 14-Stunden-Tagen. Ich hatte 125 Tests, die 12 Minuten dauerte zu laufen. Ich hatte keine Ahnung, was ich tat, und es fühlte sich langsam, aber es fühlte sich stetig, und die Ergebnisse waren fantastisch. Ich im Wesentlichen wieder schrieb in 3 Wochen, was ursprünglich 3 Monate dauerte etwas falsch laufen. Wenn ich es jetzt geschrieben habe, konnte ich es wohl in 3-5 Tagen. Der Unterschied? Meine Testsuite würde 500 Tests, die 1-2 Sekunden zu laufen nehmen. Das kam mit der Praxis.

Answer 4

Als Anfänger Programmierer, das, was ich gefunden heikel über testgetriebene Entwicklung war die Idee, dass die Prüfung zuerst kommen sollte.

Um den Neuling, das ist nicht wirklich wahr. Design an erster Stelle. (Schnittstellen, Objekte und Klassen, Methoden, was auch immer in Ihrer Sprache geeignet ist.) Dann schreiben Sie Ihre Tests darauf. Dann schreiben Sie den Code, der tatsächlich Sachen tut.

Es ist eine Weile her, seit ich war in dem Buch gesucht, aber Beck scheint zu schreiben, als ob der Entwurf des Codes einfach irgendwie unbewusst im Kopf passiert. Für erfahrene Programmierer, sein, dass möglicherweise wahr, aber für noobs wie ich, Nuh-uh.

fand ich die ersten paar Kapitel von Code Complete für das Denken über Design wirklich nützlich. Sie unterstreichen die Tatsache, dass Ihr Design ändern kann gut, auch wenn Sie auf der Nitty Gritty Ebene der Umsetzung sind nach unten. Wenn das passiert, können Sie auch müssen die Tests neu schreiben, weil sie auf den gleichen Annahmen wie Ihr Design beruhten.

Codierung ist hart. Lassen Sie uns gehen.

Answer 5

Für Punkt eins finden Sie unter Frage , fragte ich eine Weile zurück zu Ihrem ersten Punkt beziehen.

Anstatt die anderen Punkte der Reihe nach behandeln, werde ich einige globale Beratung bieten. Trainieren. Es dauerte eine ganze Weile und ein paar ‚zwielichtigen‘ Projekte (persönliche obwohl) zu tatsächlichen get TDD. Gerade Google für viel mehr zwingende Gründe, warum TDD ist so gut.

Trotz der Tests das Design meines Codes fahren, bekomme ich noch ein Whiteboard und einige Design kritzeln aus. Daraus zumindest haben Sie eine Vorstellung davon, was Sie tun werden sollen. Dann produzieren ich die Liste der Tests pro Gerät, dass ich glaube, ich brauche. Sobald Sie anfangen zu arbeiten, mehr Funktionen und Tests in die Liste hinzugefügt.

Eine Sache, die aus Ihrer Frage stand ist der Akt der Tests wieder neu zu schreiben. Das klingt wie Sie Verhaltenstests durchgeführt, anstatt Zustand. Mit anderen Worten, klingen auch die Tests eng mit Ihrem Code. Somit ist eine einfache Änderung, die nicht den Ausgang nicht beeinflusst wird einige Tests durchbrechen. Modultests (zumindest gute Einheit Testen) ist auch eine Fähigkeit zu meistern.

empfehle ich die Google Testing Blog ziemlich schwer, weil einige der Artikel dort meinen Tests für TDD gemacht Projekte viel besser.

Answer 6

Die die genannten Rohre wurden hinter der rechten Schnittstelle setzen, zu ändern, wie diese Schnittstelle (von Named Pipes-Buchsen an einem anderen Steckdose Bibliothek) Tests nur Auswirkungen für die Komponente sollen, dass Geräte, die eine Schnittstelle implementiert. So Dinge mehr schneiden / anders geholfen hätte ... Das Interface die Buchsen hinter sind, werden wahrscheinlich zu entwickeln.

begann ich vor TDD vielleicht 6 Monate zu tun? Ich lerne immer noch selbst. Ich kann meinen Tests und Code haben viel besser geworden sagen im Laufe der Zeit, es so halten. Ich auch wirklich das Buch XUnit Design Patterns empfehlen.

Answer 7

  

Wie macht man eine solche Liste hinzuzufügen   und streichen von der Führung   Entwicklungsprozess? Ich hatte zunächst ein   wenige Artikel wie „Server starten soll   up „“ sollten Server abbrechen, wenn Kanal   nicht verfügbar“ist

Produkte in TDD ToDo-Listen sind feinkörnigem als das, sie wollen ein Verhalten eine Methode nur bei Prüfung, zum Beispiel:

• Test erfolgreich Client-Verbindung
• Test-Client-Verbindungsfehler Typ 1
• Test-Client-Verbindungsfehler Typ 2
• Test erfolgreich Client-Kommunikation
• Test-Client-Kommunikation schlägt fehl, wenn nicht verbunden

Sie können eine Liste von Tests (positiv und negativ) für jedes Beispiel bauen Sie gab. Wenn darüber hinaus Einheit Testen Sie begründen keine Verbindung zwischen dem Server und dem Client. Sie haben soeben invoke Methoden isoliert, ... Diese Antworten Frage 3.

  

Wie Sie umschreibt behandeln?

Wenn das Gerät Testverhalten und nicht die Implementierung testet, dann haben sie nicht neu geschrieben werden. Wenn Unit-Test-Code wirklich eine Named Pipe schafft mit Produktionscode zu kommunizieren, und dann offensichtlich haben die Tests modifiziert werden, wenn sie von Rohr Steckdose geschaltet wird. Unit-Tests wird bleiben von externen Ressourcen wie Dateisysteme weg, Netzwerke, Datenbanken, weil sie langsam sind, können nicht verfügbar sein ... sehen diese Unit Testing Regeln .

Das bedeutet, die niedrigste Stufe Funktion wird nicht als Einheit getestet, werden sie mit Integrationstests getestet werden, wo das ganze System End-to-End getestet wird.