Aus Entwicklungssicht organisieren Sie zunächst die Variablen und Funktionen nach bestimmten Namen und Formaten. Beginnen Sie dann mit dem Schreiben von Code. In der Branche befürworten viele als Nächstes das Testen von Einheiten.
TDD ist die englische Abkürzung für Test-Driven Development. Es handelt sich um eine Kernpraxis und -technologie in der agilen Entwicklung und eine Designmethodik. Das Prinzip von TDD besteht darin, Unit-Testfallcode zu schreiben, bevor Funktionscode entwickelt wird.
1. Drei Gesetze von TDD
Gesetz 1 Schreiben Sie keinen Produktionscode, bevor Sie Unit-Tests schreiben, die nicht bestanden werden können.
Gesetz 2: Sie können nur Unit-Tests schreiben, die einfach nicht bestanden werden. Ein Fehler beim Kompilieren gilt nicht als Fehler.
Gesetz drei: Schreiben Sie nur Produktionscode, der gerade ausreicht, um den aktuell fehlgeschlagenen Test zu bestehen.
Tests werden zusammen mit dem Produktionscode geschrieben, die Tests werden nur wenige Sekunden vor dem Produktionscode geschrieben.
2. Halten Sie den Test sauber
Testcode ist genauso wichtig wie Produktionscode und muss ordentlich genug gehalten werden.
Alles Gute kommt mit dem Testen.
Ein sauberer Unit-Test-Code bringt viele Vorteile für Ihren Code. Je schmutziger die Tests, desto schmutziger wird letztendlich auch der Code. Wenn Tests fehlen, beginnt der Code zu verrotten.
3. Sauberes Testen
Sauberes Testen hat ein sehr wichtiges Element: Lesbarkeit.
Testcode sollte klar, sauber und aussagekräftig genug sein. Sagen Sie im Test möglichst viel in möglichst wenigen Worten.
Testmodus: Bau-Betrieb-Inspektion,
Der erste Schritt besteht darin, die Testdaten zu erstellen
Der zweite Schritt besteht darin, die Testdaten zu betreiben
Der dritte Schritt besteht darin, den Vorgang zu überprüfen. Ob die erwarteten Ergebnisse erzielt werden.
3.1 Sprache für bestimmte Felder testen
Verwenden Sie Testsprachentests, um die Lesbarkeit zu verbessern.
3.2 Doppelte Standards
Der Code in der Test-API hat andere technische Standards als der Produktionscode. Er sollte einfach, prägnant und ausdrucksstark sein, aber er sollte genauso effektiv sein wie der Produktionscode .
4. Eine Behauptung pro Test
Manche Leute denken, dass jede Testfunktion eine und nur eine Behauptungsanweisung haben sollte.
Testen Sie jeweils ein Konzept.
Eine bessere Regel könnte sein, nur ein Konzept zu testen und in jeder Testfunktion eine Sache zu tun.
5. F.I.R.S.T.-Prinzipien
Sauberer Code sollte den folgenden Regeln folgen:
Schnelle Tests sollten schnell genug sein. Tests sollten schnell ablaufen.
Unabhängige Tests sollten unabhängig voneinander sein. Ein Test sollte keine Bedingungen für den nächsten Test festlegen.
Wiederholbare Tests sollten in jeder Umgebung wiederholt bestanden werden.
Selbstvalidierende Tests sollten eine boolesche Ausgabe haben. Unabhängig davon, ob der Test fehlschlägt oder bestanden wird, sollte die Schlussfolgerung direkt gezogen werden, anstatt das Protokoll zu überprüfen, um zu bestätigen, ob der Test bestanden wurde oder nicht.
Zeitnahe Tests sollten zeitnah geschrieben werden. Unit-Tests sollten direkt vor dem Produktionscode geschrieben werden, der sie erfolgreich macht.
6. Zusammenfassung
Testen ist genauso wichtig wie Code. Es gewährleistet und verbessert die Skalierbarkeit, Wartbarkeit und Wiederverwendbarkeit von Produktionscode. Halten Sie Ihre Tests klar, ausdrucksstark und kurz. Erfunden als Test-API für domänenspezifische Sprachen, um Ihnen beim Schreiben Ihrer eigenen Tests zu helfen.
In der tatsächlichen Entwicklung verfügen viele Teams aufgrund verschiedener externer und interner Faktoren, enger Baupläne, kurzer Zeit, schwerer Aufgaben usw. nicht über TDD oder Unit-Tests für viele Dinge. Trotzdem müssen wir uns trotzdem daran halten Halten Sie sich an dieses Prinzip und nähern Sie sich langsam dem Ziel des Unit-Tests ...
Das könnte Ihnen gefallen:
Wie wird man durch Selbststudium ein hervorragender Full-Stack-Ingenieur?
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
