TDD und Unit Testing für kurze Projekte mit kleinen Teams?

Question

Ist TDD ein guter Ansatz für kleine und kurze Projekte, die von kleinen Teams bis zu 4 Personen durchgeführt werden? Ist das wirklich eine gewinnbringende Anstrengung?

Was ist mit Unit Testing? TDD impliziert Unit Testing, aber nicht umgekehrt. Wäre der Komponententest während des Projektentwicklungszyklus von Zeit zu Zeit nicht ausreichend, bis eine angemessene Codeabdeckung erreicht ist?

Answer 1

Die Antwort ist JA! Und aus dem folgenden Grund. Stellen Sie sich folgendes Szenario vor. Sie und Ihr Projektteam haben eine großartige Anwendung erstellt und beschließen, sie in Produktion zu bringen. Nach einer Weile kommt ein Benutzer zu Ihnen und sagt: Hey Leute, ich habe einen Fehler in Ihrer Anwendung gefunden. Können Sie ihn bitte reparieren? Natürlich sagst du ja den Bug und der User ist glücklich. Erst nach einer Weile kommt er zurück und sagt, großartig, dass du das Problem behoben hast, aber jetzt, wo etwas funktioniert hat, kannst du es nicht mehr reparieren?

Wenn Sie TDD verwendet und Unit-Tests für die Anwendung durchgeführt hätten, wäre das Szenario nicht so. Dies liegt daran, dass Tests für Ihre gesamte Anwendung durchgeführt wurden. Nach dem Beheben eines Fehlers führen Sie einfach die Komponententests erneut aus, um zu sehen, ob Ihr "Fix" keine anderen Dinge in Ihrer Anwendung bricht.

Diese Antwort ist mehr auf die Verwendung von Komponententests ausgerichtet. Das Folgende ist TDD selbst.

Was TDD Sie als Individuum macht, ist darüber nachzudenken, was ich im Folgenden (Objekt, Klasse, Funktion usw.) programmieren werde. Was sind die Kanten meines Codes? Was ist, wenn ich/else-Anweisungen brauche, nach denen ich suchen muss? Wenn Sie alleine oder in einem Projektteam von 20 Personen sind, spielt dies keine Rolle. Die Sache mit TDD ist der Denkprozess von Ihnen, nicht die anderen Leute in Ihrem Projekt.

Answer 2

Wenn Sie UnitTesting tun, ist es nur ein kleiner Schritt, um TDD zu übernehmen. Aber Sie werden viel mehr davon profitieren.

Nur ein Beispiel: TDD definiert, dass Sie zuerst Ihre Tests implementieren. Dies bedeutet, dass Sie über das Ziel nachdenken, das Sie erreichen möchten, bevor Sie mit der Implementierung beginnen. Dies führt zu besserem Code.

Answer 3

Für mich kommt es nicht darauf an, ob das Projekt klein oder kurz ist. TDD, richtig gemacht, ist in der Lage, schnell eine Reihe von Tests zu starten, die das volle Vertrauen in den Code bieten. Es wurde auch viel über TDD geschrieben, was dazu beitrug, auch für Projekte das passende Design zu entwickeln.

Man könnte also argumentieren, dass TDD am besten für kleine und kurze Projekte geeignet ist, weil man nur den Code schreibt, den man benötigt, um die Tests bestanden zu haben und nichts anderes. Daher die Kosten niedrig halten. Dann gibt es den zusätzlichen Vorteil, Vertrauen in die Tests und den Code zu haben, wenn Sie später Änderungen vornehmen.

Der nächste kleine Punkt, den ich machen würde, ist, dass viele Projekte klein und kurz beginnen. Diese Interimslösungen können zu strategischen Plattformen für die Entwicklung werden (wenn sie Erfolg haben).

Answer 4

TDD und Unit Testing sind keine Alternativen zueinander. In jedem Projekt sollten Sie Ihren Code testen, hier führen Sie Unit Testing und Integration und System Testing durch.

TDD ist jedoch ein Entwicklungsmodell. Wie Waterfall und andere Entwicklungsmethoden ist auch TDD eine Methode. In TDD haben Sie einige grundlegende Anforderungen und Sie schreiben Komponententests, um sicherzustellen, dass die Anforderungen implementiert und funktionsfähig sind. Wenn Sie Komponententests schreiben, stellen Sie jedoch fest, dass Sie mehr Funktionen und Klassen implementieren müssen, um die Hauptanforderungen zu erfüllen. Einheitentests in diesem Zusammenhang machen andere Anforderungen klarer.

Angenommen, Sie müssen eine Anwendung schreiben, die den Namen des Computers ausgibt, auf dem die Anwendung ausgeführt wird. Zuerst schreiben Sie einen Komponententest:

[Test] 
public void ProducedMessage_IsCorrect() 
{ 
    AreEqual(BusinessLibrary.ProduceMessage(), System.Environment.MachineName); 
} 

und dann merkt man, Sie die ProduceMessage Funktion implementieren müssen. Sie implementieren es so einfach wie es geht, so dass der Komponententest besteht. Sie schreiben die Methode so:

public string ProduceMessage() 
{ 
    return "MyComputer"; 
} 

Dann führen Sie den Test und es besteht. Danach senden Sie Ihren Code und andere Mitglieder des Teams erhält den Code. Wenn sie den Test ausführen, schlägt der Test fehl, da Sie den Name Ihres Computers in dem Code fest codierten.

So ein paar weise Mitglied Ihres Teams ändert den Code in die richtige Form und Sie gehen weiter.

Es geht um die Auswahl von Entwicklern mit TDD-Erfahrung. Zumindest einige von ihnen sollten erfahrene TDD-Entwickler sein, denke ich.

Answer 5

Vor kurzem habe ich einen schönen Blogpost von Szymon Pobiega, mit dem Titel If you are not doing TDD… gelesen. Ich ermutige wirklich, einen Blick darauf zu werfen. Es liegt daran, dass ich TDD etwas skeptisch gegenüberstehe und es in große Gewohnheiten des Entwicklungslebenszyklus stelle, als eine ultimative Lösung für die Sicherheit Ihres Projekts, abgesehen von der Art des Projekts. Ich mag dieses Fragment:

TDD ist am nützlichsten, wenn Sie absolut keine Ahnung über die Form von den Code haben. In diesem Fall hackst du besser nicht den Code so schnell wie du kann. Machen Sie statt dessen einen kleinen Schritt nach dem anderen und bestätigen Sie jedes Mal, dass das Ergebnis ist. Im Idealfall tun Sie es in einem Paar. Jeder Schritt, den Sie ausführen, ermöglicht es Ihnen, mehr Tests zu entdecken, die geschrieben werden müssen. Ich liebe die Analogie Dan in seiner Präsentation verwendet: es ist einfach wie Schwimmen gegen Gehen in 1,50 Meter tiefen Pool. Sie können den ganzen Weg durchgehen und sicherstellen, dass jedes Mal, wenn einer Ihrer Füße auf dem Boden ist oder Sie einfach schwimmen können, das ist riskanter (kein Bodenkontakt), aber Sie bewegen sich viel schneller. TDD ist wie zu Fuß.

Er verweist auf Dan North session from NDC 2012.