Das Schreiben von Spezifikationen - Behauptungen oder Testhypothesen - wird in TDD-Kursen normalerweise umgangen, da nur wenig Programmierung vorhanden ist.
Sie sind jedoch sehr wichtig.
Sie bestimmen, wie und welche Tests geschrieben werden und wie einfach es sein wird, die Störung zu beheben. Sie benötigen fast keine Zeit für die Implementierung. Sie sind die ersten, die den Benutzer der Story und den Code verbinden, und die ersten, die den Fehler des Testcodes anzeigen. Sie schützen uns zusätzlich vor Fehlern im Code des Tests.
Wie könnten wir unsere Aussagen verbessern?
Erstens
sollten sich die
Spezifikationen in Bezug auf die User Story beziehen . Wenn der Benutzer der Story den Begriff "Anmelden" verwendet, kann assert diesen Begriff nicht ändern, um ihn zu authentifizieren / zu autorisieren / zu validieren. Wenn die Geschichte nicht gut geschrieben ist, ändern Sie sie.
Zweitens muss die
Spezifikation explizit den Namen der Komponente enthalten , die sie beschreibt. Dies kennzeichnet den Testbereich und signalisiert einen Fehler, wenn der Fischadler plötzlich häufig unerwartete Komponenten enthält.
Das gültige Skript ist gut mit dem Prinzip der Einzelverantwortung kombiniert, daher muss der Name der Komponente mit der Beschreibung des Tests übereinstimmen. Wenn es viele gültige Szenarien gibt, hat die Komponente wahrscheinlich zu viel Verantwortung.
Außerdem beschreibt ein Szenario in der Regel entweder ein UI-Ereignis oder eine Art Muster. Gute Kandidaten für den Komponentennamen können den Namen des Musters enthalten: Validator, Strategie, Builder, Transformer, Controller usw. Oder Ereignisname: Submitter, Login, ReadonlyOrderView usw. Das heißt, Abhängig vom Namen der Komponente müssen sowohl die Eingabe- als auch die Ausgabewerte der Hauptfunktion der Klasse definiert werden. Schlechte Namen: zu abstrakt (Service, Komponente, Helfer, Dienstprogramm) und doppelt (ValidatorAndRenderer).
Drittens müssen die
Spezifikationen ausdrücklich Bedingungen angeben .
Schlecht:
@Test public void testValidatePassword(){}
Besser:
@Test public void loginController_whenValidUsername_andValidPassword_shouldLogUserIn(){}
Wir müssen diese Funktion nicht von einem anderen Ort aus aufrufen, daher sind besonders lange Namen gültig. Wenn die Anzahl der Bedingungen im Test nicht auf die Linie passt, sollten Sie möglicherweise die Struktur der Komponente ändern.
Für Javascript-Tests das gleiche, aber Sie können dort Bedingungen setzen, es stellt sich als bequemer heraus.
describe('login UI component', () => { describe('when username provided', () => { describe('when valid password', () => { it('should log user in', () => { ... }); }); }); });
Explizite Bedingungen sind leichter zu lesen und
fehlen .
Wenn die Bedingung nicht mit dem geschriebenen Testcode übereinstimmt, ist der Code außerdem leicht zu korrigieren.
Eine gute Beschreibung ist im Allgemeinen ein Ersatz für Dokumentation und Codekommentar. Es ist abstrakt, es hängt nicht vom Framework und dem Compiler ab und es sollte mit der gleichen Ernsthaftigkeit wie die letzten beiden behandelt werden.
Die Bedingungen selbst müssen im Code konsistent sein, damit sie leicht gelesen werden können, z. B. GIVEN-WHEN-THEN-SOLLTEN usw.
Viertens
sollten die Spezifikationen gestrafft werden . Es ist nützlich, sie in umgekehrter Reihenfolge zu schreiben:
Fehler zuerst, Nullen zuerst, glücklicher Pfad zuletzt. Dann besteht kein Wunsch, den Test nach einem gültigen Benutzerfall zu beenden. Für UI-Komponenten: Rendern, Ereignisse. Für zustandsbehaftete Komponenten sind alle Zustände konsistent.
Daher sieht die Struktur einer gut lesbaren Spezifikation folgendermaßen aus: 5-10 fehlerhaft, ein gültiges Skript (oder mehrere Variationen eines Skripts)
Wenn Sie eine Spezifikation schreiben, empfiehlt es sich, sie vollständig in Form eines Textes zu schreiben und sie dann von Ihrem Kollegen lesen zu lassen, um Klarheit und fehlende Bedingungen zu gewährleisten. Dann können Sie bereits mit dem Schreiben der Implementierung beginnen. Sehr oft ist in dieser Form die Aufgabe entfremdet, d.h. Nun, wenn jemand anderes die Testimplementierung schreibt.
Fünftens sollte die
Durchführung des Tests dem entsprechen, was in Beschreibung beschrieben ist .
Es ist eine gute Praxis, sich in Arrangement-Act-Assert zu unterteilen, um leicht eine Übereinstimmung für den einen oder anderen Teil der Implementierung zu finden. Der Text von Behauptungen und Ausnahmen, falls vorhanden, sollte auch mit Testbeschreibungen korreliert werden. In der Regel können wir sie einfach duplizieren.
Wenn Sie dem Test Bedingungen oder Zusicherungen hinzufügen, müssen Sie natürlich auch die Testbeschreibungen aktualisieren.
Die Reihenfolge des Schreibens der Spezifikation kann also wie folgt sein.
- User Story lesen
- Namenskomponente und gültiges Skript
- Bedingungen für ein gültiges Szenario formulieren
- Ergänzen Sie die Spezifikation mit fehlerhaften Skripten, indem Sie sie oben platzieren
- Lassen Sie den Nachbarn die fehlenden lesen und korrigieren
- Implementieren Sie Tests und Komponenten nacheinander mithilfe einer Rot-Grün-Refaktor-Schleife.