Single wichtigste Sache zu vermitteln, wenn TDD Unterricht

Question

Ich arbeite mit einer Gruppe von Fachleuten zusammen, um eine Veranstaltung zu erstellen, um zu helfen, die Praxis von TDD zu Menschen zu lehren, die interessiert sind, aber keine Erfahrung (Novizen).

Wir versuchen, Labs, Workshops usw. zu entwickeln, und ich versuche, an die einzelne, größte Sache zu denken, die wir diesen Individuen vermitteln müssen, um ihnen zu helfen, TDD in Zukunft erfolgreich zu praktizieren.

Was würden Sie sagen, wir sollten unsere Priorität für das Lernen machen? Welcher Aspekt des Teachens von TDD ist der am wichtigsten. Wenn Sie zwei Dinge tun müssen, ist das in Ordnung, ich werde Sie nicht auf den SINGLE-Teil halten :)

Answer 1

It's about design. Es ist NICHT über die Tests.

Answer 2

Überspringen Sie keine Schritte im Prozess. Es dauert länger, um in den ursprünglichen Groove von TDD zu gelangen, aber sobald es vorhanden ist, ist der gesamte SDLC schneller und weit fehlerfreier.

Rot - Grün - Refactor -> tun Sie es einfach.

Answer 3

Meiner Erfahrung nach ermöglicht es die Verwendung von TDD, dass ich und mein Team unseren Code gnadenlos umgestalten, ohne uns Gedanken darüber machen zu müssen, dass irgendwo etwas Unerwartetes kaputt geht.

Also ich denke, für mich der wichtigste Aspekt von TDD ist die Abdeckung, da eine gute Abdeckung gibt mir das Vertrauen zu refactor, wenn ich einen Platz in der Codebasis, die es verwenden kann.

Answer 4

Nur weil Ihre Tests bestanden haben, heißt das nicht, dass der Code korrekt ist.

Abgesehen davon würde ich sagen, dass es wichtig ist zu prüfen, in Ihrem Design zu testen. Wenn Ihr Code schwer zu testen ist, ohne die interne Implementierung des zu testenden Geräts genau zu kennen, sollten Sie das Design überdenken. Andernfalls wird das Refactoring risikoträchtiger, da die Tests wahrscheinlich mit dem Code geändert werden müssen.

Answer 5

Ich schlage vor: "Sei geduldig." Es fühlt sich am Anfang komisch an. Für mich waren es wahrscheinlich drei Projekte, bevor es sich natürlich anfühlte.

Answer 6

Umgang mit dem Drängen von TDD, wenn die Termine knapp werden. Dies ist eines der größten Probleme, mit denen ich Menschen und Teams mit TDD geholfen habe. Sie hatten Schwierigkeiten, die Wichtigkeit und den Wert des Fallenlassens anstelle von Tests für das höhere Management auszudrücken.

Answer 7

Fahren Sie in Baby-Schritten fort.

Stellen Sie sicher, dass Ihre Tests nur einen sehr kleinen Bereich abdecken und, wie PhlipCPP sagt: 'Führen Sie die MINIMALE EDIT durch, um den Test bestanden zu haben. '

Trotzdem gibt es eine Menge an TDD, also müssen Sie immer noch sicherstellen, dass Sie nichts verpassen.

Answer 8

Betonen Sie verschiedene Arten von Tests. Sowohl Black-Box-Tests als auch White-Box-Tests sind wichtig und haben unterschiedliche Zwecke. Whitebox-Tests sind nicht geeignet, um die Korrektheit zu überprüfen, da sie das Gesamtsystem nicht testen können. Es dient dazu, Code-Gerüche noch stinkiger zu machen und damit eine bessere Refactoring-Richtung zu bieten. Black-Box-Test ist da, um die Korrektheit zu testen. Jedes Feature sollte Black-Box-getestet werden.

Hervorheben Sie auch Unterschiede in der Testabdeckung.Aufgrund von Kombinations- und Wiederholbarkeitsproblemen ist es nicht möglich, jeden Codepfad in Ihrer Anwendung zu testen. Meine Regel ist, dass ein Feature nicht abgeschlossen ist, bis es Black-Box-getestet ist. Sie sollten den Schülern helfen, ihre eigenen Regeln herauszufinden. Whitebox-Tests sollten jedoch keine externen Klassenabhängigkeiten aufweisen. Daher sollte jede Zeile jeder Klasse im White-Box-Test getestet werden.

Answer 9

Ich stimme mit dem, was Jon said in his answer, aber ich denke, eine wichtige logische Folge, dass Testbarkeit ist nicht „gutes Design“ diktieren, sondern ist nur ein Indikator, dass Ihr Design in am Ziel.

Answer 10

Ich weiß nicht, ob das als das wichtigste Ding zählen würde - aber es war etwas, das mich etwas Zeit gekostet hat, als ich das erste Mal mit TDD experimentierte.

Schreiben Sie den Code nicht in Ihren Kopf, bevor Sie den Test schreiben.

Als ich mit TDD anfing, "wusste" ich, was das Design sein sollte. Ich "wusste", welchen Code ich schreiben wollte. Also schrieb ich einen Test, mit dem ich diesen Code schreiben konnte.

Als ich dies tat, ich war nicht wirklich TDD tun - da ich den Code schreibt zuerst (auch wenn der Code nur in meinem Kopf war :-)

Es dauerte einige Zeit (und einige Stocher durch clevere Leute) zu erkennen, dass Sie sich auf den Test konzentrieren müssen. Schreiben Sie den Test für das gewünschte Verhalten - schreiben Sie dann den minimalen Code, der benötigt wird, um ihn zu bestehen - lassen Sie dann das Design durch Refactoring entstehen. Wiederholen bis fertig.

Answer 11

TDD dreht sich alles um den Rhythmus (rot, grün, refactor). Den Rhythmus herunter zu bekommen, bringt einen über den "Buckel", wenn man es nicht versteht. Und wenn Sie den Rhythmus nicht herunterfahren, werden Sie wahrscheinlich nicht lange bei TDD bleiben. Die Essenz des Rhythmus ist Baby Steps, die bereits erwähnt wurde. Schreibe so wenig Code wie möglich und korrigiere gnadenlos um.

Eine Sache zu betonen ist, dass TDD einige kurzfristige Gewinne für langfristige diejenigen handelt. Wenn Sie mit TDD beginnen, wird Ihre Produktivität unweigerlich sinken. Aber wenn du erst einmal den Rhythmus gelernt hast, ist es ähnlich, in einen Groove einzusteigen, und es kann dir tatsächlich dabei helfen, schneller zu arbeiten. Ganz zu schweigen von der Nebenwirkung von TDD ist eine ständig wachsende Basis von Komponententests, die Regressionstests bereitstellen. Eine Unvermeidbarkeit von Software besteht darin, dass Systeme, die gewartet werden (ohne eine Reihe von automatisierten Regressionstests), sich im Laufe der Zeit verschlechtern.

Answer 12

Betonen Sie, dass TDD ein Paradigmenwechsel für Entwickler s ist. Wenn Sie ein neues Team aufstellen, erkennen Sie, dass es bis zu sechs Monate dauern wird, bis das Team als TDD-Praktiker voll wirksam wird. Sobald Sie ein reifes, agiles Team haben, das effektiv TDD trainiert, wird die Paarung es einem neuen Entwickler ermöglichen, nach ein paar Iterationen in Schwung zu kommen. Wenn Sie Paare aus einem Team verwenden, um eine neue Linie zu bilden, können Sie die neue Linie schneller auf TDD beschleunigen als die erste Linie.

In den Projekten, die wir gemessen haben, haben wir einen sechsfachen Rückgang der Defekte gesehen, die während des automatisierten Funktions-/Regressionstests gefunden wurden, nachdem das Team TDD gelernt hatte. Das sind erhebliche Einsparungen. Darüber hinaus spiegelt der Code ein saubereres Design mit weniger Codezeilen für jedes Feature wider. TDD aber ein virtueller Stopp zur Vergoldung. TDD ist am effektivsten, wenn Ihre Storykarten Akzeptanzkriterien haben.

TDD ermöglicht auch eine nachhaltige Tempo. Das Team wird feststellen, dass es bei jeder Iteration immer noch die gleiche Anzahl von Funktionen geben kann, da der Code sauber und mit wenigen Fehlern bleibt. Sowohl bei TDD- als auch bei automatisierten Funktions-/Regressionstests werden während der Benutzerakzeptanzprüfung häufig keine Fehler festgestellt.