it-swarm.com.de

Gibt es einen Unterschied zwischen TDD und Test First Development (oder Test First Programming)?

Beide Ideen klingen mir sehr ähnlich, aber es kann subtile Unterschiede geben oder genau dasselbe, was auf unterschiedliche Weise erklärt wird. Welche Beziehung besteht zwischen TDD und Test First Development/Programming?

52
Thomas Owens

Es gibt einen Unterschied in Bezug auf den treibenden Faktor.

Haben Sie eine vage Vorstellung davon, wie die Klasse (oder das System - dies kann natürlich in verschiedenen Maßstäben geschehen) aussehen soll, und überlegen Sie sich dann Tests, die ihr die tatsächliche Form geben? Das ist TDD.

Wissen Sie genau, wie die öffentliche API der Klasse aussehen soll, und schreiben Sie die Tests einfach vor der Implementierung? Das ist Test-First-Entwicklung.

Mein Stil ist eher eine Mischung aus beidem. Manchmal ist es offensichtlich, wie die API aussehen sollte, bevor Tests geschrieben werden - in anderen Fällen bestimmt die Testbarkeit das Design.

Anders ausgedrückt beginnt TDD mit "Welche Fragen möchte ich stellen?" Nicht-TDD (ob zuerst getestet oder nicht) beginnt mit "Welche Antwort möchte ich geben?"

60
Jon Skeet

Es handelt sich im Grunde genommen um verschiedene Namen, die dasselbe beschreiben - und zwar fünf Namen, da das letzte D sowohl für Design als auch für Entwicklung stehen kann.

Test First war der Begriff, der ursprünglich, insbesondere im Kontext der extremen Programmierung, für den Test-Code-Refactor-Zyklus verwendet wurde. Der Name Test Driven Development wurde später vorgeschlagen - und schnell übernommen -, um die Tatsache hervorzuheben, dass TFD mehr eine Designstrategie als eine Teststrategie ist und war.

Offensichtlich haben heute einige Leute unterschiedliche Konnotationen für diese beiden Begriffe, aber das war nicht die Absicht hinter ihrer Existenz, und ich würde mich nicht darauf verlassen, dass es allgemein bekannt ist (weil es nicht so ist). Tatsächlich würde ich den Begriff TFD eher als veraltet ansehen.

24
Ilja Preuß

Es gibt viele ähnliche Begriffe wie Test-First-Programmierung, Test-First-Entwicklung, Test-Driven-Entwicklung oder sogar Test-Driven-Design. Es ist wichtig, einige Punkte zu klären:

1. Test First Programming (TFP)

Der Begriff Test-First-Programmierung ist eine bewährte Programmierpraxis. Es wurde von Kent Beck in seinem Buch „Extreme Programming Explained“ (Extreme Programmiererklärung) wieder eingeführt: „Schreiben Sie Unit-Tests vor dem Programmieren und lassen Sie alle Tests jederzeit laufen“. Wenn wir also von Test-First-Programmierung sprechen, sprechen wir über das Schreiben automatisierter Komponententests durch den Entwickler, der den Code schreiben wird, um diese Tests zu erfüllen. Die Komponententests häufen sich und erstellen eine automatisierte Regressionstestsuite, die regelmäßig ausgeführt werden kann.

2. Test Driven Development (TDD)

Testgetriebene Entwicklung (TDD) ist der Name einer von Kent Beck in seinem Buch "Test Driven Development by Example" eingeführten Methodik. Es ist ein Software-Entwicklungsprozess, bei dem es nicht nur darum geht, Tests vor dem Code zu schreiben. Das ganze Buch versucht es durch Muster, Arbeitsabläufe, Kultur usw. zu erklären. Ein wichtiger Aspekt dabei ist die Betonung des Refactorings.

Einige Leute gebrauchen die Begriffe Test-First-Entwicklung, Test-Driven-Design oder Test-Driven-Programmierung und ... Eines ist sicher: Die etablierte Methodik ist Test-Driven-Entwicklung und die Programmiertechnik ist Test-First-Programmierung. Der Rest bezieht sich entweder allgemein auf die Idee, Tests vor dem Code zu schreiben, oder fälschlicherweise auf die testgetriebene Entwicklung oder die Test-First-Programmierung.

13
jurgenreza

TDD = TFD + Refactoring.

Wenn Sie TFD ausführen, wenden Sie einige Umgestaltungen an, um den Code allgemeiner und robuster zu gestalten.

10
Santosh Gokak

Historisch korrekt: Test-First-Programmierung und testgetriebene Entwicklung bedeuten dasselbe mit einem verbesserten Namen

Im Kontext von XP (Extreme Programming), dem Softwareentwicklungsprozess, der Test-First Programming und Test-Driven Development populär gemacht hat, wurde Test-First Programming in Test-Driven Development und dann Test-Driven Development umbenannt. Driven Design nach der Erkenntnis, dass sich das Schreiben von Tests zunächst enorm positiv auf die Softwarearchitektur und das Design eines Softwaresystems auswirkt.

Dieser Einfluss auf Architektur und Design ist eine Folge mehr oder weniger überraschender Synonyme:

  • Testbar
  • Entkoppelt
  • Wiederverwendbar
  • Unabhängig einsetzbar
  • Unabhängig entwickelbar
  • Unabhängig vernünftig

Software-Entitäten können nur dann leicht wiederverwendet, getestet, unabhängig bereitgestellt, unabhängig entwickelt oder getrennt begründet werden, wenn sie entkoppelt sind. Das Schreiben von Tests vor der eigentlichen Implementierung ist eine nahezu kugelsichere Methode, um eine kontinuierliche Entkopplung sicherzustellen.

Dieser Einfluss auf das Softwaredesign und die Architektur wurde neben den anderen positiven Effekten so wichtig, dass es sich für die Entwickler lohnte, ihn von Test-First Programming in Test-Driven Development umzubenennen.

Der Name Test-Driven Development trägt auch dazu bei, die Methode in Bezug auf Akzeptanz und Verständnis besser zu vermarkten, da der Name Test-Driven Development die ganzheitlichen Aspekte der Methode besser hervorhebt als Test-First Programming.

Nicht historisch korrekt, aber nützlich

Obwohl historisch nicht korrekt, finde ich die folgende Unterscheidung sehr nützlich:

Test-First-Programmierung…

… Ist eine Methode, bei der Tests für den zu testenden Code vor dem zu testenden Code geschrieben werden.

Testgetriebene Entwicklung…

… Ist eine spezifische Teilmenge der Test-First-Programmierung, die den drei von Robert C. Martin beschriebenen Gesetzen der testgetriebenen Entwicklung folgt:

  1. Sie können keinen Seriencode schreiben, bis Sie zuerst einen fehlerhaften Komponententest geschrieben haben.
  2. Sie können nicht mehr von einem Komponententest schreiben, als zum Fehlschlagen ausreicht, und das Nicht-Kompilieren schlägt fehl.
  3. Sie können nicht mehr Seriencode schreiben, als ausreicht, um den derzeit fehlgeschlagenen Komponententest zu bestehen. - Robert C. Martin, Die drei Gesetze der testgetriebenen Entwicklung

Das Befolgen dieser drei Regeln versetzt Sie in den sogenannten Rot-Grün-Refaktor-Zyklus. 1. Sie schreiben einen nicht bestandenen Test. 2. Du machst es vorbei. 3. Nachdem der Test erfolgreich abgeschlossen wurde, können Sie eine unbarmherzige Umgestaltung vornehmen, bevor Sie den nächsten fehlgeschlagenen Test schreiben.

Beachten Sie, dass für ein sicheres Refactoring Tests erforderlich sind. Refactoring bedeutet, die Struktur des Quellcodes zu ändern, ohne das signifikante Verhalten zu ändern. Aber woher wissen wir, dass wir nicht versehentlich signifikantes Verhalten geändert haben? Was definiert signifikantes Verhalten? Dies ist eines der vielen Dinge, für die Tests nützlich sind.

Übrigens, wenn Ihre Tests dem Refactoring im Wege stehen, sind Ihre Tests zu niedrig, zu eng miteinander verbunden und möglicherweise haben Sie zu viel Spott verwendet.

Weitere interessante Umbenennungen in Extreme Programming

  • Kontinuierliche Integration -> Kontinuierliche Bereitstellung -> Kontinuierliche Bereitstellung; Streng genommen bedeuten sie verschiedene Dinge, aber im Sinne von XP bedeutete dies von Anfang an eine kontinuierliche Bereitstellung, und als die Leute auf den Zug sprangen, wurde erkannt, dass die Integration zu wörtlich genommen wurde und die Leute aufhörten, bevor sie fertig waren.
  • Kontinuierliches Refactoring -> Kontinuierliche Designverbesserung; Refactoring ist kein Mittel zum Selbstzweck, sondern verfolgt einen höheren Zweck.
  • 40 Stunden Woche -> Nachhaltiges Tempo (Urban Legende: Diese Umbenennung geschah nach Protesten französischer Softwareentwickler.)
6
Christian Hujer

Sie sind genau das gleiche. Beide Referenzschreibtests schreiben zuerst und schreiben dann den Code, der den Test bestehen wird

1
Matt Briggs

TDD (Test Driven Development) ist Test First Development/Programming, obwohl ich gesehen und gehört habe, dass TDD das Erstellen von dauerhaften, wiederholbaren Komponententests (auch nach dem Code) bedeutet, aber es impliziert, dass die Tests geschrieben werden, bevor der Code getestet wird.

1
Jim Anderson

In Test Driven Development: Am Beispiel gibt der Autor Kent Beck klar an, dass "test first" (TF) die Regel ist. TF ist also das Prinzip, das TDD regiert. Der spätere ist der Prozess.

0
Begueradj