Ich möchte mit dem Testen unserer Anwendung beginnen, weil ich glaube, dass dies der erste Schritt zur Entwicklung einer guten Beziehung zum Testen ist und es mir erlauben wird, mich auf andere Arten von Tests zu konzentrieren, die interessantesten BDD mit Gurke.
Wir generieren derzeit alle unsere Basisklassen mit Codesmith, die vollständig auf den Tabellen in einer Datenbank basieren. Ich bin neugierig auf die Vorteile der Generierung von Testfällen mit diesen Basisklassen? Sind das schlechte Testpraktiken?
Das führt mich zu der ultimativen Frage meines Posts. Was testen wir bei Unit Tests?
Testen wir die Beispiele, von denen wir wissen, dass wir sie wollen? oder testen wir die Beispiele, die wir nicht wollen?
Sie können Methoden sein, die mehrere Arten des Scheiterns und mehrere Arten von Erfolg haben, wie können wir wissen, wann wir aufhören sollen?
Nehmen Sie zum Beispiel eine Summierungsfunktion. Gib es 1,2 und erwarte 3 im einzigen Unit-Test .. woher wissen wir, dass 5,6 nicht zurück 35 kommt?
Frage wiederholen
Der Punkt der Komponententests soll Ihnen Sicherheit geben (aber nur in besonderen Fällen gibt es Ihnen Sicherheit), dass das tatsächliche Verhalten Ihrer öffentlichen Methoden dem erwarteten Verhalten entspricht. Also, wenn Sie eine Klasse Adder
und ein entsprechender Komponententest
%Vor%Dies gibt Ihnen ein gewisses (aber nicht 100%) Vertrauen, dass sich die zu testende Methode angemessen verhält. Es gibt Ihnen auch eine gewisse Abwehr gegen das Brechen des Codes beim Refactoring.
Was testen wir bei Unit Tests?
Das tatsächliche Verhalten Ihrer öffentlichen Methoden gegenüber dem erwarteten (oder angegebenen) Verhalten.
Testen wir die Beispiele, von denen wir wissen, dass wir wollen?
Ja, ein Weg, Vertrauen in die Korrektheit Ihrer Methode zu gewinnen, besteht darin, einige Eingaben mit bekannter erwarteter Ausgabe zu machen, die öffentliche Methode an der Eingabe auszuführen und die aktuelle Ausgabe mit der erwarteten Ausgabe zu vergleichen.
Beginnen Sie mit Ihren Anforderungen und schreiben Sie Tests, die das erwartete Verhalten testen. Von diesem Zeitpunkt an kann die Anzahl der anderen Szenarien, die Sie testen, durch Ihren Zeitplan oder möglicherweise durch das Erkennen von Nicht-Erfolgsszenarien, die besonders risikoreich sind, gesteuert werden.
Sie sollten in Erwägung ziehen, Nicht-Erfolgstests nur als Reaktion auf Fehler zu erstellen, die Sie (oder Ihre Benutzer) feststellen (die Idee ist, dass Sie einen Test schreiben, der den Fehler repariert, bevor Sie den Fehler beheben, sodass der Test fehlschlägt Wenn dieser Fehler in zukünftigen Entwicklungen wieder in Ihren Code eingefügt wird.
Was zu testen ist: Alles, was jemals schiefgelaufen ist.
Wenn Sie einen Fehler finden, schreiben Sie einen Test für das fehlerhafte Verhalten , bevor Sie den Code reparieren. Dann, wenn der Code richtig funktioniert, wird der Test bestanden, und Sie haben einen weiteren Test in Ihrem Arsenal.
1) Zum Starten empfehle ich Ihnen, die Kernlogik Ihrer App zu testen.
2) Verwenden Sie dann das Code-Coverage-Tool in vs, um zu sehen, ob Ihr gesamter Code in Tests verwendet wird (alle Zweige von if-else, Fallbedingungen werden aufgerufen). Dies ist eine Art Antwort auf Ihre Frage zum Testen von 1 + 2 = 3, 5 + 6 = 35: Wenn Code abgedeckt ist, können Sie sich mit weiteren Experimenten sicher fühlen.
3) Es ist eine gute Übung, 80-90% des Codes abzudecken: Der Rest der Arbeit ist normalerweise uneffizient: Getter-Setter, 1-Zeilen-Ausnahmebehandlung, etc.
4) Erfahren Sie mehr über die Trennung von Bedenken.
5) Generierungseinheitstests - versuchen Sie es, Sie werden sehen, dass Sie eine schöne Codezeile speichern können, indem Sie sie manuell schreiben. Ich bevorzuge die Erzeugung der Datei mit vs, dann schreibe den Rest TestMethods von mir selbst.
Sie testen die Dinge wo Sie
In Ihrem Beispiel würde es also wenig Sinn machen, die generierten Klassen zu testen. Testen Sie stattdessen den Generator.
Es empfiehlt sich, zuerst die wichtigsten Anwendungsfälle (für welche die getestete Funktion entwickelt wurde) zu testen. Dann testen Sie die Hauptfehlerfälle. Dann schreiben Sie Tests für Eckfälle (d. H. Untere und obere Grenzen). Die ungewöhnlichen Fehlerfälle sind normalerweise so schwer zu erzeugen, dass es keinen Sinn macht, sie zu testen.
Wenn Sie eine große Anzahl von Parametersätzen überprüfen müssen, verwenden Sie datengetriebene Tests.
Wie viele Dinge Sie testen, ist eine Frage von Aufwand und Rendite, also kommt es wirklich auf das einzelne Projekt an. Normalerweise versuchen Sie, der 80/20-Regel zu folgen, aber es gibt Anwendungen, bei denen Sie mehr Testabdeckung benötigen, da ein Fehler sehr schwerwiegende Konsequenzen hätte.
Sie können die Zeit, die Sie zum Schreiben von Tests benötigen, drastisch reduzieren, wenn Sie einen testgesteuerten Ansatz (TDD) verwenden. Das liegt daran, dass Code, der nicht mit Testbarkeit geschrieben wurde, viel schwieriger ist, manchmal fast unmöglich zu testen. Aber da nichts im Leben frei ist, ist der mit TDD entwickelte Code tendenziell komplexer.
Ich beginne auch den Prozess der einheitlicheren Verwendung von Komponententests und was ich gefunden habe, ist, dass die größte Aufgabe bei Komponententests die Strukturierung meines Codes ist, um das Testen zu unterstützen. Während ich darüber nachdenke, wie man Tests schreibt, wird klar, wo Klassen übermäßig gekoppelt sind, bis zu dem Punkt, dass die Komplexität der "Einheit" das Definieren von Tests schwierig macht. Ich verbringe so viel oder mehr Zeit damit, meinen Code umzuformen, wie ich Tests schreibe. Sobald die Grenzen zwischen testbaren Einheiten klarer werden, löst sich die Frage, wo der Test beginnen soll; Beginne mit deinen kleinsten isolierten Abhängigkeiten (oder zumindest denen, um die du dir Sorgen machst) und arbeite dich nach oben.
Es gibt drei grundlegende Ereignisse, die ich testen möchte: min, max und irgendwo zwischen min und max.
Und gegebenenfalls zwei Extreme: unter min und über max.
Es gibt offensichtliche Ausnahmen (ein Code hat zum Beispiel nicht unbedingt ein Minimum oder Maximum), aber ich habe festgestellt, dass das Testen von Einheiten für diese Ereignisse ein guter Anfang ist und die Mehrzahl der "gewöhnlichen" Probleme mit dem Code erfasst. p>
Tags und Links unit-testing testing code-generation