TDD mit unklaren Anforderungen

Question

Ich weiß, dass TDD viel hilft und ich mag diese Methode der Entwicklung, wenn Sie zuerst einen Test erstellen und dann die Funktionalität implementieren. Es ist sehr klar und richtig.

Aber aufgrund einiger meiner Projekte passiert es oft, dass wenn ich ein Modul entwickle, ich sehr wenig darüber weiß, was ich will und wie es am Ende aussehen wird. Die Anforderungen erscheinen, während ich mich entwickle, es kann 2 oder 3 Iterationen geben, wenn ich den alten Code ganz oder teilweise lösche und neu schreibe.

Ich sehe zwei Probleme: 1. Ich möchte das Ergebnis so schnell wie möglich zu verstehen, sind meine Ideen richtig oder falsch. Komponententests verlangsamen diesen Prozess. So passiert es oft, dass ich Komponententests nach dem Ende des Codes schreibe, was bekanntermaßen ein schlechtes Muster ist. 2. Wenn ich zuerst die Tests schreibe, muss ich nicht nur den Code zweimal oder mehrmals, sondern auch die Tests neu schreiben. Es braucht viel Zeit.

Könnte mir bitte jemand sagen, wie kann TDD in einer solchen Situation angewendet werden?

Vielen Dank im Voraus!

Answer 1

Ich möchte das Ergebnis so schnell wie möglich zu verstehen, sind meine Ideen richtig oder falsch. Komponententests verlangsamen diesen Prozess.

Ich stimme nicht zu. Komponententests und TDD können die Ergebnisse oft schneller beschleunigen, da sie Sie zwingen, sich auf die Ergebnisse zu konzentrieren, anstatt Tonnen von Code zu implementieren, die Sie vielleicht nie brauchen. Es ermöglicht Ihnen auch, die verschiedenen Teile Ihres Codes während des Schreibens auszuführen, so dass Sie ständig sehen können, welche Ergebnisse Sie erhalten, anstatt warten zu müssen, bis Ihr gesamtes Programm fertig ist.

Answer 2

TDD hilft Ihnen, die Absicht Ihres Codes auszudrücken. Das bedeutet, dass Sie beim Schreiben des Tests sagen müssen, was Sie von Ihrem Code erwarten. Wie Ihre Erwartungen erfüllt werden, ist sekundär (das ist die Implementierung). Stellen Sie sich die Frage: "Was ist wichtiger, die Implementierung oder was ist die zur Verfügung gestellte Funktionalität?" Wenn es die Implementierung ist, müssen Sie die Tests nicht schreiben. Wenn es die zur Verfügung gestellte Funktionalität ist, hilft Ihnen das Schreiben der Tests als Erstes.

Eine weitere wertvolle Sache ist, dass Sie mit TDD keine Funktionalität implementieren, die nicht benötigt wird. Sie schreiben nur Code, der die Absicht erfüllen muss. Dies wird auch YAGNI genannt (Du wirst es nicht brauchen).

Answer 3

Ich finde, dass TDD in dieser Art von Situation besonders gut funktioniert; in der Tat würde ich sagen, dass das Vorhandensein von unklaren und/oder sich ändernden Anforderungen tatsächlich sehr häufig ist.

Ich finde, dass die beste Verwendung von TDD ist sicherzustellen, dass Ihr Code tut, was Sie erwarten, dass es tut. Wenn Sie einen Code schreiben, sollten Sie wissen, was Sie tun möchten, ob die Anforderungen klar sind oder nicht. Die Stärke von TDD besteht darin, dass Sie bei einer Änderung der Anforderungen einfach einen oder mehrere Komponententests ändern können, um die geänderten Anforderungen zu berücksichtigen. Aktualisieren Sie anschließend Ihren Code, während Sie sicher sind, dass Sie keine anderen brechen) Funktionalität.

Ich denke, dass eine Sache, die eine Menge Leute mit TDD stolpert, die Annahme ist, dass alle Tests im Voraus geschrieben werden müssen. Ich denke, es ist effektiver, die Faustregel zu verwenden, dass Sie niemals einen Implementierungscode schreiben, während alle Ihre Tests bestanden werden. Dies stellt lediglich sicher, dass der gesamte Code abgedeckt ist, und stellt gleichzeitig sicher, dass Sie überprüfen, ob der gesamte Code das tut, was Sie tun möchten, ohne sich darum sorgen zu müssen, dass Sie alle Ihre Tests im Voraus schreiben.

Answer 4

In dieser frühen Prototyp-Phase finde ich es genug, um testbaren Code zu schreiben. Das heißt, wenn Sie Ihren Code schreiben, denken Sie darüber nach, wie Sie einen Test ermöglichen können, aber konzentrieren Sie sich zunächst auf den Code selbst und nicht auf die Tests.

Sie sollten die Tests haben, wenn Sie etwas festschreiben.

Answer 5

Hier ist ein Blogbeitrag, den ich gefunden habe, um die Verwendung von TDD auf einem sehr iterativen Designprozess zu erklären: http://blog.extracheese.org/2009/11/how_i_started_tdd.html.

Answer 6

Die Verwendung von TDD könnte Sie tatsächlich dazu bringen, Code schneller zu schreiben - ein Test für ein bestimmtes Szenario nicht schreiben zu können, könnte bedeuten, dass ein Problem in den Anforderungen besteht.
Wenn Sie TDD finden Sie diese problematischen Orte schneller statt nach dem Schreiben von 80% Ihres Codes.

Es gibt ein paar Dinge, die Sie tun können, Ihre Tests beständigen ändern zu machen:

1. Sie sollten versuchen, Code in Ihre Tests in einer Form Fabrik Methoden wieder zu verwenden, die Ihren Test erstellt Objekte zusammen mit Verify-Methoden , die das Testergebnis überprüft. Diese Weg, wenn einige wichtige Verhaltensänderung in Ihrem Code auftritt, haben Sie weniger Code in Ihrem Test zu ändern.

2. Verwendung IoC-Container statt Argumente auf Ihre Hauptklassen vorbei - wieder, wenn die Methodensignatur Änderungen, die Sie brauchen, um alle Tests nicht zu ändern.

3. Machen Sie Ihre Komponententests kurz und isoliert - jeder Test sollte nur einen Aspekt Ihres Codes überprüfen und Mocking/Isolation Framework verwenden, um den Test unabhängig von externen Objekten zu machen.

4. Code nur für die erforderliche Funktion (YAGNI) testen und schreiben. Versuchen Sie sich selbst zu fragen, welchen Wert mein Kunde aus dem Code, den ich schreibe, erhalten wird. Erstellen Sie keine überkomplizierte Architektur, sondern erstellen Sie die benötigte Funktionalität Stück für Stück, während Sie Ihren Code während des Umbaus refaktorisieren.

Answer 7

Es gibt keine von ihm wegzukommen - wenn Sie messen, wie lange es nur, wie lange zu kodieren dauert es dauert Klassen zu schreiben, etc, dann wird es länger dauern, mit TDD. Wenn Sie erfahren sind, wird es etwa 15% hinzufügen, wenn Sie neu sind, dauert es mindestens 60% länger, wenn nicht mehr.

ABER, insgesamt werden Sie schneller sein. Warum?

• durch einen Test zu schreiben erste, was Sie spezifizieren Sie wollen und mehr, genau das und nichts zu liefern - daher Zeit mit dem Schreiben nicht verwendeten Code
• ohne Tests zu speichern, könnte man denken, dass die Ergebnisse so offensichtlich sind, dass das, was Sie habe getan, ist richtig - wenn es nicht ist. Tests zeigen, dass das, was Sie getan haben, korrekt ist.
• werden Sie schneller Feedback von automatisierten Tests erhalten als durch manuelle Tests tun
• mit manueller Test der Zeit, alles zu testen genommen, wie Ihre Anwendung schnell zunimmt wächst - es ist
• mit tun manuelle Tests, was bedeutet, Sie werden es stoppen leicht zu machen Fehler und "sehen" etwas passieren, wenn es nicht ist, das ist besonders wahr, wenn Sie sie wieder und wieder und wieder laufen
• (gut) Unit Tests geben Sie einen zweiten Client auf Ihren Code, der oft hervorhebt Design-Probleme, die Sie sonst vermissen könnten

Addieren Sie all dies und wenn Sie von Anfang bis zur Lieferung messen, ist TDD viel, viel schneller - Sie erhalten weniger Fehler, Sie nehmen weniger Risiken auf, Sie schreiten mit konstanter Geschwindigkeit voran (was die Schätzung erleichtert) und die Liste geht weiter .

TDD wird Sie schneller machen, keine Frage, aber es ist nicht einfach und Sie sollten sich etwas Platz zu lernen und nicht entmutigen, wenn es zunächst langsamer scheint.

Schließlich sollten Sie einige Techniken von BDD betrachten, um zu verbessern, was Sie mit TDD tun. Beginnen Sie mit der Funktion, die Sie implementieren möchten, und fahren Sie von dort aus mit dem Code fort, indem Sie Storys und dann Szenarien erstellen. Konzentrieren Sie sich darauf, Ihr Lösungsszenario nach Szenario in dünnen vertikalen Schichten zu implementieren. Dies wird helfen, die Anforderungen zu klären.

Answer 8

IMHO, Ihr Hauptproblem ist, wenn Sie etwas Code löschen müssen. Dies ist Verschwendung und das ist, was zuerst angesprochen werden soll.

Vielleicht könnten Sie prototype oder verwenden "Spike-Lösungen", um die Anforderungen und Ihre Ideen zu validieren, wenden Sie dann TDD auf den realen Code, sobald die Anforderungen stabil sind.

Das Risiko besteht darin, dies zu verwenden und den Prototyp zu versenden.

Auch Sie könnten zuerst den "sonnigen Pfad" testen und nur die restlichen wie Fehlerbehandlung implementieren ... nachdem die Anforderungen festgeschrieben wurden. Die zweite Phase der Implementierung wird jedoch weniger motivierend sein.

Welchen Entwicklungsprozess verwenden Sie? Es klingt agil, da Sie Iterationen haben, aber nicht in einer Umgebung, die es vollständig unterstützt.

Answer 9

Joshua Block kommentierte etwas ähnliches in dem Buch "Coders at work". Sein Rat war, Beispiele zu schreiben, wie die API verwendet werden würde (ungefähr eine Seite lang). Dann denke viel über die Beispiele und die API nach und refactoriere die API. Schreiben Sie dann die Spezifikation und die Komponententests. Bereiten Sie sich jedoch darauf vor, die API umzuformen und die Spezifikation neu zu schreiben, während Sie die API implementieren.

Answer 10

TDD wird für fast jeden die ursprüngliche Entwicklung verlangsamen. Wenn also die anfängliche Entwicklungsgeschwindigkeit 10 auf einer Skala von 1 bis 10 ist, können Sie mit TDD eine 8 erreichen, wenn Sie kompetent sind.

Es ist die Entwicklung nach dieser Punkt, der interessant wird. Wenn Projekte größer werden, sinkt die Entwicklungseffizienz - oft auf 3 im selben Maßstab. Mit TDD ist es sehr möglich, immer noch in der 7-8-Reihe zu bleiben.

Suchen Sie nach "technischen Schulden" für eine gute Lektüre. Soweit es mich betrifft, ist jeder Code ohne Komponententests tatsächlich technische Schulden.

Answer 11

Wenn ich mich mit unklaren Anforderungen befasse, weiß ich, dass sich mein Code ändern muss. Durch solide Tests kann ich meinen Code besser ändern. Das Üben von TDD hilft mir solide Tests zu schreiben und deshalb mache ich es.

Obwohl TDD in erster Linie eine Konstruktionstechnik ist, hat es einen großen Vorteil in Ihrer Situation: es ermutigt den Programmierer, Details und konkrete Szenarien zu berücksichtigen. Wenn ich das mache, merke ich, dass ich ziemlich schnell Lücken oder Missverständnisse oder Unklarheiten in den Anforderungen finde. Der Versuch, Tests zu schreiben, zwingt mich dazu, mit dem Mangel an Klarheit in den Anforderungen umzugehen, anstatt zu versuchen, diese Schwierigkeiten unter den Teppich zu kehren. Wenn ich also unklare Anforderungen habe, übe ich TDD, weil es mir hilft, die spezifischen Anforderungsprobleme zu identifizieren, die ich angehen muss, aber auch, weil es mich ermutigt, Code zu schreiben, den ich leichter ändern kann was ich bauen muss.