In Anbetracht eines kurzen Sprints ist es immer akzeptabel, auf TDD zu verzichten, um "Dinge innerhalb des Sprints zu erledigen".
Zum Beispiel kann eine gegebene Arbeit ein Drittel des Sprints erfordern, um das Objektmodell um eine existierende Implementierung herum zu entwerfen. In diesem Szenario könnten Sie am Ende mit implementiertem Code, etwa auf halbem Weg durch den Sprint, ohne Tests fertig werden (das Implementieren von Komponententests während dieser "Design" -Stufe würde einen erheblichen Aufwand bedeuten und die Tests würden wahrscheinlich einige Male bis zum Schluss verworfen "Design" ist festgelegt).
Sie könnten dann einen oder zwei Tage in der zweiten Woche damit verbringen, Unit- / Integrationstests nachträglich hinzuzufügen.
Ist das akzeptabel?
Eine 2-wöchige Iteration ist nicht zu kurz für viele Leute. Viele von uns machen eine Woche Iterationen. Kent Beck versucht sogar, tägliche Bereitstellungen zu fördern - und es gibt Vorteile, wenn es darum geht, den Entwicklungsprozess zu verbessern, damit er so schnell reagiert.
NIEMALS die TDD-Qualität reduzieren, um Material rauszubekommen - Es ist so viel schwieriger, später aufzuräumen und man bringt dem Kunden einfach bei, dass er Druck auf schnelle, dreckige, gehackte Veröffentlichungen ausüben kann. Sie sehen nicht den Mist-Code, der daraus entsteht - und sie erhalten ihn nicht. Wenn jemand versuchte, mich dazu zu bringen, würde ich aufhören ... und ich habe mich geweigert, an Orten zu arbeiten, die "keine Zeit haben, um richtig zu testen". Das ist keine Entschuldigung, die funktioniert.
HINWEIS: Wenn ich über TDD schreibe, füge ich Funktionstests hinzu. Diese sind wichtig, weil sie Szenarien ausführen sollten, die für den Kunden in Bezug auf erkennbare Benutzergeschichten Sinn ergeben. Normalerweise fange ich an, mit dem Funktionstest an einer Geschichte zu arbeiten, weil es der wichtigste Test ist - "Testkunde bekommt, was sie beschrieben haben ..." Alle anderen Tests könnten verhandlungsfähig sein, aber wenn ich teamführend bin erwarte mindestens einen Funktionstest pro Geschichte oder es ist (wie Menschen sagen) "nicht fertig!" ; -)
Glaub nicht, dass du später hineingehen und Tests hinzufügen kannst - es ist so viel schwieriger, das zu tun. (Ich habe es in beide Richtungen versucht - glauben Sie mir.) Es ist wirklich billiger, Tests zu setzen, wenn Sie gehen - auch wenn Sie umgestalten und neu schreiben müssen oder etwas wegwerfen, wenn sich das System weiterentwickelt.
Sie können keinen Qualitätscode erhalten, ohne ständig eine angemessene Codeabdeckung zu haben.
Codetest Abdeckung ist das wichtige Wort hier. Dinge zu bedecken, die kaputt gehen könnten, und nicht nur zahllose bedeutungslose Tests - kritische Tests, die Dinge abdecken, über die man sich Sorgen machen muss.
Wenn Sie es nicht rechtzeitig herausbekommen und es ein Problem ist, müssen Sie sich überlegen warum?
Ich würde sagen, dass es fast immer akzeptabel ist, einen Prozess zu umgehen, wenn dies bedeutet, dass Sie ein Projekt abschließen, das Sie sonst nicht fertig stellen könnten. Die Prozesse sollten da sein, um Ihnen zu helfen, aber wenn Ihr Prozess nicht hilft, dann verwenden Sie ihn nicht (nachdem Sie ihn natürlich zuerst mit dem Rest des Teams besprochen haben).
Das Umgehen von TDD kann jedoch leicht den gegenteiligen Effekt zur Folge haben - Sie könnten fehlerhaften Code schreiben, der kurz vor dem Versand eine Neuschreibung erfordert, da finale Tests kritische Probleme aufzeigen, die Sie früher hätten erkennen sollen .
Wenn Sie Unit-Tests auslassen, um etwas aus der Tür zu bekommen und Glück haben, dass es funktioniert, sollten Sie es als eine technische Schuld sehen, die so schnell wie möglich zurückgezahlt werden sollte.
Meiner Erfahrung nach dauert das Schreiben von richtigen Komponententests mindestens so lange, wie man den zu testenden Code schreibt, so dass es mir schwer fällt zu sehen, wie man Tests in "einem Tag" schreibt oder zwei ".
Das heißt, was "akzeptabel" ist, hängt von vielen Dingen ab. Behandeln Sie Tests nicht als religiöses Problem. Die Tests geben Ihnen ein gewisses Maß an Vertrauen in Ihren Code. Sie müssen nur erkennen, dass Sie durch den Verzicht auf Tests auch Ihr Risiko erhöhen. Manchmal ist das angebracht, manchmal nicht.
Die beiden Extreme, auf die Sie achten sollten:
Sagen Sie, Sie schreiben die Tests später und kommen dann nie dazu. Dies ist "Kredit von der Zukunft", und Sie können schnell mehr Schulden anhäufen, als Sie zurückzahlen können.
Verbringe mehr Zeit mit Tests als gerechtfertigt. Es gibt bestimmte Risiken, die so gering sind, dass es keinen Sinn macht, sie zu testen, wenn die erwarteten Kosten für etwas, das schief läuft, geringer sind als die Kosten für das Schreiben des Tests.
Meiner Meinung nach kann dies ein gefährlicher Kompromiss sein. Obwohl es manchmal akzeptabel ist, schafft es doch einen Präzedenzfall, der nur schwer überstürzt werden kann. Ich weiß, wo ich arbeite, für einige komplizierte Dinge neigen wir dazu, etwas ein paar Mal umsetzen zu müssen, um schließlich zu einer guten Umsetzung zu kommen, da die Idee von etwas Besserem in unserem Projekt immer wieder auftaucht.
>Normalerweise können beim Erstellen der Tests fehlende Anforderungen abgefangen werden, und es kann zunächst ein vollständigeres Design erstellt werden, bevor eine Menge Code erstellt wird, da sonst ein Stapel Code vorhanden ist, den man möglicherweise wiederverwenden möchte viel lieber als wegwerfen und etwas besser von Grund auf neu zu bauen.
Der Schlüssel besteht darin, diese Tests in der zweiten Woche durchführen zu können, anstatt sich auf etwas Neues zu konzentrieren, das ein Arbeitselement mit Priorität 1 zu sein scheint. Während dies für einige in Ordnung sein kann, für andere kann es ein Rezept für Katastrophen, IME sein.
Nach Ihrer Beschreibung machen Sie TDD nicht wirklich, da die Tests nicht das Design steuern. Es ist eher so, dass Sie Komponententests durchführen, was immer noch eine gute Sache ist.
In Bezug auf die grundlegende Frage, können Sie auf Tests verzichten, wirklich ist dies etwas, das nur Erfahrung (des Teams) Sie in Bezug auf was der Kompromiss ist führen kann. Im Allgemeinen wirst du es bereuen, aber manchmal ist ein schneller schlechter Hack besser, als überhaupt nicht zu liefern.
Vielleicht vermisse ich etwas, aber Sie tun entweder TDD nach den allgemein vereinbarten Prinzipien, oder Sie operieren wie ein TDD-Frachtkult.
Wenn Ihr Team / Ihre Firma die Entscheidung getroffen hat, TDD zu verwenden, und Sie dabei bleiben möchten, benötigen Sie entweder längere Sprints oder Sie müssen den Umfang der Funktionalität innerhalb der zwei Wochen reduzieren.
die Durchführung von Unit-Tests während dieser "Design" -Phase würde einen erheblichen Aufwand bedeuten und die Tests würden wahrscheinlich einige Male weggeworfen werden, bis das endgültige "Design" auf
festgelegt ist
Ich habe festgestellt, dass Test-Driven Design mich schneller zum endgültigen "Design" bringt: in weniger Iterationen und oft ist der erste Schuss der letzte. Entwurfsiterationen werden normalerweise benötigt, da das Programm ohne Reality-Checks entworfen wird und nachfolgende Implementierungsbemühungen und Benutzungsversuche die Redesigns vorantreiben. Mit TDD ist der Realitätscheck die ganze Zeit vorhanden. Das kann genug sein, um sicherzustellen, dass Sie das Zeichen nicht verpassen und das Ding neu gestalten müssen.
Wenn Sie keinen Code versenden, was nützen Sie dann als Entwickler? Das Wichtigste ist, Code vor Ihren Benutzern zu erhalten. Wenn dies bedeutet, einen Teil des Prozesses zu opfern, um ein Projekt abzuschließen, dann tue es. Der CEO wird Ihnen keinen Bonus für die Implementierung von TDD und nicht für den Versand geben.
Gute Tests verdoppeln die Zeit bis zum Ende. Wenn das Management-Team Sie für länger nimmt, dann ist das der Punkt, an dem das Metall in realen Projekten ins Fleisch fällt, oder?
Ich finde, dass TDD die Praxis eines Zeloten ist, verschwendet Zeit, die Tests versagt, die Kompilierungsfehler, Refactoring-Tests und Code zu Tode und dergleichen. Am Ende, solange Sie eine gute Testabdeckung des Codes erhalten, können Sie Zeit sparen, indem Sie Komponententests erstellen, unmittelbar nachdem das Feature kompiliert und gestartet wurde.
Dies ist eher eine geschäftliche als eine technische Entscheidung. Muss der Code wirklich funktionieren oder nur so aussehen, als ob er funktioniert?
Hier ist es einmal akzeptabel:
Sie haben ein neues Produkt, das kaum jemand benutzt und Ihre Kopfverkäufe Person geht in eine Branche Konferenz, um es zu demonstrieren. Sie Vertrauen Sie ihr, um irgendwelche Fehler zu tanzen reingehen. Die Konferenz wird aufgebaut Interesse an Ihrem Produkt und Verkauf wird in den folgenden 3-6 Monaten fließen. Ihr Unternehmen hat noch 8 Monate Geld übrig die Bank.
Hier ist es einmal nicht akzeptabel:
Ihr Code steuert die Röntgenhardware in 5.000 Krankenhäuser. Sie rollen aus eine neue Version. Du willst nicht töten Menschen. Ihre Firma wird verklagt werden in Vergessenheit geraten, wenn Sie groß machen Fehler.
Es gibt eine Geschwindigkeit zwischen Entwicklung und Qualitätskompromiss. Das ist eine geschäftliche Entscheidung. Hoffen wir, dass Sie einen Manager haben, der das verstehen will.
Tags und Links unit-testing tdd agile sprint