Wir beginnen jetzt mit einem leeren Projekt. Sie möchten etwas tun, sagen Sie zwei Zahlen teilen. Sie schreiben also einen Test, der beschreibt, was Sie tun möchten:
%Vor% Dieser Test gibt Ihnen einen Einstiegspunkt: Er beschreibt die akzeptable Schnittstelle der Methode divide . So implementieren Sie es zum Beispiel als int divide(int x, int y) .
Schreiben Sie Tests, die beschreiben, was Sie von Ihrem Code erwarten. Du musst nicht viel darüber nachdenken. Die normalste Art, Ihre Erwartungen zu schreiben, ist wahrscheinlich der beste Weg, um Ihren Code zu entwerfen, und dann können Sie ihn implementieren, um Ihren Test zu erfüllen.
Es gibt ein paar Schritte zum Testen. Von MSDN ;
In Ihrem Fall;
%Vor% Assert class überprüft Bedingungen in Komponententests mit true / false Propositionen. Sie sollten Ihre Testfälle so schreiben, wie Sie ihre Ergebnisse erwarten. Sie können das Attribut TestMethod für Ihre Testmethoden verwenden. Es gibt einen coolen Post über Unit-Tests für Ihren c # -Code erstellen . Analysiere es sehr gut.
Beginnen Sie mit einem Stub der Funktion / Klasse / Komponente, die Sie entwickeln möchten. Es sollte kompilieren, aber absichtlich (noch) nicht tun, was es tun soll.
Zum Beispiel:
%Vor%oder
%Vor%Denken Sie über das beabsichtigte Verhalten nach und behandeln Sie den Stub als Schnittstelle zu einer Blackbox. Kümmere dich nicht um die Implementierung (noch). Denken Sie an den "Vertrag" der Schnittstelle: X geht rein, Y geht raus.
Identifizieren Sie Standardfälle und wichtige Fälle. Schreibe Tests für sie.
Für die Integer-Division (vorausgesetzt, wir würden sie von Grund auf neu schreiben) gibt es tatsächlich einige Fälle: Mit und ohne Rest, n / 1, n / 0, 0 / n, 0/0, negative Zahlen, usw.
%Vor%Kompilieren Sie die Komponententests und führen Sie sie aus. Scheitern sie alle? Wenn nicht, warum? Vielleicht funktioniert einer der Tests nicht wie vorgesehen (Tests können auch fehlerhaft sein!).
Beginnen Sie jetzt mit der Implementierung, bis kein Test mehr fehlschlägt.
Beginnen Sie damit, den Unterschied zwischen Theorie und Praxis zu erkennen.
Jedes System im realen Leben wird Dinge haben, die leicht mit TDD erstellt werden und andere, die es nicht sind.
Die letzte Gruppe ist alles abhängig von der Umgebung, wenn man an einem System arbeitet, das nicht versucht, Umweltannahmen wegzuspalten, sondern diese pragmatisch akzeptiert.
Diese Gruppe kann auf TDD-Basis entwickelt werden, erfordert jedoch zusätzliche Werkzeuge und Erweiterungen für die Softwarefabrik.
Für .Net wären das Tools und Erweiterungen wie MS Virtual Test Lab und SpecFlow.
Was ich mitteilen möchte, ist, dass es darauf ankommt .
Bei sehr einfachen Komponenten- / Komponententests besteht die Idee darin, einen fehlerhaften Testfall zu schreiben, bevor der zu testende Code geschrieben wird, und die Entwicklung zu beenden, wenn der Test erfolgreich ausgeführt wird.
Für Integrationstests und darüber hinaus (Systemtests) müssen Sie unter anderem überlegen, wie Sie die Testumgebung in einen bekannten Zustand bringen und zusätzlich überlegen, was Sie testen möchten.