Ein klares JA mit TDD (und mit wenigen Ausnahmen)
In Ordnung umstritten, aber ich würde argumentieren, dass jedem, der diese Frage mit "Nein" beantwortet, ein grundlegendes Konzept von TDD fehlt.
Für mich ist die Antwort ein klares Ja, wenn Sie TDD folgen. Wenn nicht, dann ist nein eine plausible Antwort.
Die DDD in TDD
TDD wird oft als Hauptvorteil von dir angeführt.
- Verteidigung
- Sicherstellen, dass sich der Code möglicherweise ändert, aber nicht sein Verhalten .
- Dies ermöglicht die sehr wichtige Praxis des Refactorings .
- Sie erhalten diese TDD oder nicht.
- Design
- Sie legen fest, was etwas tun soll, wie es sich verhalten soll, bevor Sie es implementieren .
- Dies bedeutet häufig fundiertere Umsetzungsentscheidungen .
- Dokumentation
- Die Testsuite sollte als Spezifikationsdokumentation (Anforderungsdokumentation) dienen.
- Die Verwendung von Tests für diesen Zweck bedeutet, dass die Dokumentation und Implementierung immer in einem konsistenten Zustand sind - eine Änderung an einem bedeutet eine Änderung an einem anderen. Vergleichen Sie dies mit den Anforderungen und dem Design eines separaten Word-Dokuments.
Trennung von Verantwortung und Umsetzung
Als Programmierer ist es furchtbar verlockend, Attribute als etwas Bedeutungsvolles und Stärkeres und Setteres als eine Art Overhead zu betrachten.
Attribute sind jedoch ein Implementierungsdetail, während Setter und Getter die vertragliche Schnittstelle sind, über die Programme tatsächlich funktionieren.
Es ist viel wichtiger zu buchstabieren, dass ein Objekt:
Ermöglichen Sie seinen Clients, seinen Status zu ändern
und
Ermöglichen Sie seinen Clients, seinen Status abzufragen
dann, wie dieser Zustand tatsächlich gespeichert wird (für die ein Attribut die häufigste, aber nicht die einzige Möglichkeit ist).
Ein Test wie
(The Painter class) should store the provided colour
ist wichtig für den Dokumentationsteil von TDD.
Die Tatsache, dass die eventuelle Implementierung trivial ist (Attribut) und keinen Verteidigungsvorteil mit sich bringt , sollte Ihnen beim Schreiben des Tests nicht bekannt sein.
Das Fehlen von Round-Trip-Engineering ...
Eines der Hauptprobleme in der Welt der Systementwicklung ist das Fehlen von Round-Trip-Engineering 1 - der Entwicklungsprozess eines Systems ist in disjunkte Unterprozesse fragmentiert, deren Artefakte (Dokumentation, Code) häufig inkonsistent sind.
1 Brodie, Michael L. "John Mylopoulos: Samen der konzeptuellen Modellierung nähen." Konzeptuelle Modellierung: Grundlagen und Anwendungen. Springer Berlin Heidelberg, 2009. 1-9.
... und wie TDD das löst
Es ist der Dokumentationsteil von TDD, der sicherstellt, dass die Spezifikationen des Systems und sein Code immer konsistent sind.
Zuerst entwerfen, später implementieren
Innerhalb von TDD schreiben wir zuerst einen Test, bei dem die Abnahme fehlgeschlagen ist, und schreiben dann den Code, der sie passieren lässt.
Innerhalb des übergeordneten BDD schreiben wir zuerst Szenarien und lassen sie dann passieren.
Warum sollten Sie Setter und Getter ausschließen?
Theoretisch ist es innerhalb von TDD durchaus möglich, dass eine Person den Test schreibt und eine andere Person den Code implementiert, der ihn bestehen lässt.
Also frag dich:
Sollte die Person, die die Tests für eine Klasse schreibt, Getter und Setter erwähnen?
Da Getter und Setter eine öffentliche Schnittstelle zu einer Klasse sind, lautet die Antwort offensichtlich Ja , oder es gibt keine Möglichkeit, den Status eines Objekts festzulegen oder abzufragen.
Wenn Sie den Code zuerst schreiben, ist die Antwort möglicherweise nicht so eindeutig.
Ausnahmen
Es gibt einige offensichtliche Ausnahmen von dieser Regel - Funktionen, die klare Implementierungsdetails enthalten und eindeutig nicht Teil des Systemdesigns sind.
Zum Beispiel die lokale Methode 'B ()':
function A() {
// B() will be called here
function B() {
...
}
}
Oder die private Funktion square()hier:
class Something {
private:
square() {...}
public:
addAndSquare() {...}
substractAndSquare() {...}
}
Oder eine andere Funktion, die nicht Teil einer publicSchnittstelle ist, die im Entwurf der Systemkomponente geschrieben werden muss.