Soll ich TDD zu Beginn eines neuen Projekts verwenden?

Question

Ich arbeite an einem neuen PHP-Projekt und obwohl ich TTD mag, finde ich, dass es in dieser Phase des Projekts eher hinderlich als hilfreich zu sein scheint.

Ich begann mit dem Schreiben von Komponententests, aber jetzt, da ich tiefer in das Prototyping einiger der Anwendungsfunktionen gehe, finde ich, dass ich Teile des Kernframeworks zusammen mit dem Schreiben der Tests neu schreibe. Es scheint nur so, als würde ich viel mehr Zeit damit verbringen, Tests neu zu schreiben, wo ich vielleicht warten sollte, bis ich in einer Alpha/Beta-Phase des Projekts bin.

Sollte ich Komponententest von Anfang an schreiben, obwohl es eine große Chance gibt, werde ich sie neu schreiben müssen?

Answer 1

Ja, es ist der beste Weg, Ihr System zu verstehen und eine solide API zu erstellen.

Es klingt, als müssten Sie Ihre Tests auf ein höheres Niveau bringen. Testen Sie keine einzelnen Methoden, testen Sie nicht die Funktionalität. The more recent buzzword is BDD or Context/Specification aber es ist nicht wirklich etwas anderes, da ich noch keinen tdd-praktizierenden getroffen habe, der nicht wenigstens versucht hat, sich in diese Richtung zu bewegen.

Answer 2

Wenn Sie TDD verwenden, beginnen Sie besser damit, es zu verwenden.

Wenn Sie glauben, es ist die richtige Wahl, dann verwenden Sie es, oder Sie haben Kopfschmerzen, wenn Sie sich entscheiden, es in der Zukunft zu verwenden.

Answer 3

Natürlich werden Sie sie neu schreiben, die Dinge werden sich ändern.

Wenn Sie eine vollständige und gründliche Anforderungsanalyse durchführen, werden sich die Dinge ändern (wahrscheinlicher hat sich geändert, während Sie diese Chimäre verfolgten) und Sie müssen erneut analysieren.

Aber wenn Sie direkt eintauchen und einige Code geschrieben und einige Ergebnisse sortiert haben, haben Sie keine nützliche Analyse, keine Tests und dann die gesamte Verkaufsabteilung reiben sich die Hände, weil geliefert = verkäuflich.

Iterieren Sie, schreiben Sie die Tests Sie können, erfüllen sie, sehen Sie, wohin Sie als nächstes gehen. TDD oder klassischer Wasserfall, es gibt viel Arbeit im Voraus, bevor Sie ein bisschen Software haben.

Tun Sie die Front arbeiten Sekunde, nicht viel Gebrauch und nie passieren sowieso.

Vielleicht müssen Sie ein bisschen mehr Proof of Concept oder Storyboarding, oder Gottheit verbieten Analyse, aber alles Tauchen in ist Lügen Smilies auf dem Armaturenbrett gesetzt, und die einzige Kredit, die Sie dafür erhalten, ist ein Kick in den Nads, wenn die Räder abheben, und sub-prime Stil technische Schuldenkrise.

Answer 4

Ich finde, dass es scheint, dass es schwieriger zu sein als hilfreich bei dieser Phase des Projekts.

Warum ist das? Können Sie Ihre Bedenken objektiv festhalten?

jetzt, wo ich bin tiefer in Prototyping von einigen der Anwendung Funktionen, finde ich mich Stücke der Kern Rahmen zusammen mit Schreiben der Tests neu zu schreiben. Es scheint nur so, als ob ich viel mehr Zeit umschreibende Tests verbringe, wo ich vielleicht warten sollte , bis ich in mehr einer Alpha/Beta-Phase des Projekts bin.

• nicht TDD Verwenden Sie, wenn Sie das Prototyping. Prototypen sollen Wissen gewinnen ... schnell in einer Zeitbox. Sobald Sie die Ungewissheit beseitigt haben, werfen Sie den Prototyp weg. Beginnen Sie dieses Mal erneut mit TDD.
• Ändern sich Ihre Tests, weil Sie jetzt einen besseren Einblick haben? Oder sind die Tests mit der Implementierung gekoppelt (weiß man, wie das Testobjekt im Vergleich zu den angebotenen Diensten implementiert wird)? Ersteres ist unvermeidbar, es sei denn, Sie haben eine vorbildliche Voraussicht. Anforderungen ändern sich, Tests ändern sich. Letzteres ist ein Geruch ... und kann vermieden werden, indem man sich auf das Was anstatt auf das Wie konzentriert?
• Das Problem mit dem Warten, bis sich Ihr Produkt/Ihre App stabilisiert hat, ist, dass Sie am Ende mit der Verschleppung aufhören ODER Sie vielleicht ein Design haben, das schwer zu testen ist. Dies macht das Schreiben von Tests (später) schwieriger als es sein müsste. TDD wird einfacher, wenn Sie in kleinen Schritten auf einer testbaren Code-Basis arbeiten. Die Tests sind auch ein Sicherheitsnetz, das Ihnen hilft, Änderungen mit Zuversicht zu machen und sofortiges Feedback zu geben.

Answer 5

• Ja, ich denke, dass es sehr wichtig ist, Tests von sehr begining Schreiben zu beginnen. Bei TDD (Test Driven Development) geht es nicht nur darum einzelne Klassen selbst zu testen. Es sollte Entscheidungen leiten, die Sie während der Entwurfsphase treffen.

• Wenn Sie zuerst Tests schreiben, werden Sie Ihr Problem besser verstehen. Sie sagen, dass Sie sie wahrscheinlich später neu schreiben werden. Wenn das der Fall ist, bedeutet das wahrscheinlich, dass Sie Ihr System besser verstehen, was eine gute Sache ist. Sie können Ihr System dann umgestalten, indem Sie weitere Tests durchführen oder vorhandene Tests erneut in die Berechnung einbeziehen.

• Es mag sich wie eine Zeitverschwendung anfühlen, aber es ist nicht so, wie Sie ein viel besseres Verständnis des Systems erhalten, an dem Sie arbeiten.

• Eines der Bücher, die ich gerade lese (Growing Object Oriented Software Guided by Tests) erwähnt ein "Walking Skeleton" -Konzept. Es schlägt vor, dass Sie TDD verwenden sollten, um eine minimale Arbeitslösung zu entwickeln, selbst wenn es sehr einfach ist.

• Ein weiterer wichtiger Punkt ist, dass Sie Ihre Implementierung von Anfang an automatisieren sollten. Dies ist nicht genau ein Komponententest, aber es ist ein Bereitstellungstest, der genauso wichtig ist wie Unit-Tests. Wenn Sie diese Art von Tests zu Beginn des Projekts durchführen, werden Sie nicht in der Nähe des Veröffentlichungsdatums von unerwarteten Problemen betroffen sein. Sie werden auch besser verstehen, wie verschiedene Komponenten Ihres Systems zusammenpassen.