Wie beginnt man mit Unit-Tests oder TDD?

Question

Ich habe viele Beiträge gelesen, die mich davon überzeugt haben, dass ich anfangen sollte, Unit-Tests zu schreiben. Ich habe auch angefangen, Dependency Injection (Unity) zu verwenden, um das Mocking zu vereinfachen, aber ich bin mir immer noch nicht ganz sicher, auf welcher Stufe ich anfangen sollte, die Unit-Tests und Mocks zu schreiben, und wie oder wo ich anfangen soll.

Wäre es besser, die Unit-Tests vor den Methoden zu schreiben, wie in der TDD-Methodik beschrieben?

Gibt es eine andere Methodik oder Vorgehensweise für Unit-Tests?

Answer 1

Wählen Sie eine kleine, unkritische Anwendung und implementieren Sie sie mit TDD. Am Anfang wird sich die neue Denkweise seltsam anfühlen, aber vielleicht fühlt sie sich nach ein oder zwei Wochen Praxis ganz natürlich an.

Hier finden Sie ein Anwendungsbeispiel (in der Verzweigung "Tutorial"), die zeigt, welche Arten von Tests zu schreiben sind. In diesem Tutorial schreiben Sie Code, um die vordefinierten Testfälle zu bestehen, damit Sie in den Rhythmus kommen, und später schreiben Sie dann Ihre eigenen Tests. Die README-Datei enthält Anleitungen. Es ist in Java geschrieben, aber Sie können es leicht an C# anpassen.

Answer 2

Ich würde TDD, test-first development, in Angriff nehmen, vor Mocks und Dependency Injection. Sicherlich können Mocks Ihnen helfen, Ihre Einheiten besser zu isolieren - und damit besser zu arbeiten Einheit Testen - aber meiner Meinung nach sind Mocking und DI fortgeschrittenere Konzepte, die die Klarheit des ersten Schreibens Ihrer Tests beeinträchtigen können.

Mocks und DI haben ihren Platz; sie sind gute Werkzeuge, die man in seinem Werkzeugkasten haben sollte. Aber sie erfordern ein gewisses Maß an Raffinesse, ein fortgeschritteneres Verständnis, als es der typische Test-Neuling hat. Ihre Tests zuerst zu schreiben, ist jedoch genau so einfach, wie es klingt. Es ist also einfacher, damit anzufangen, und es ist allein schon leistungsstark (ohne Mocks und DI). Wenn Sie zuerst Tests ohne Mocks schreiben, werden Sie schneller und einfacher Erfolg haben, als wenn Sie versuchen, mit Mocks zu beginnen, und TDD, und DI auf einen Schlag.

Beginnen Sie mit test-first; wenn Sie sehr gut damit zurechtkommen und wenn Ihr Code Ihnen sagt, dass Sie Mocks brauchen, dann über Spöttelei.

Answer 3

Ich habe für Unternehmen gearbeitet, die es mit den Unit-Tests/Integrationstests zu weit treiben, und für solche, die das zu wenig tun, so dass ich glaube, ein gutes Gleichgewicht zwischen beiden zu haben.

Ich würde TDD - Test Driven Development - empfehlen. Dies stellt sicher, dass Sie eine gute Abdeckung haben, aber es konzentriert auch Ihre Aufmerksamkeit auf die richtige Stelle und das richtige Problem.

Das erste, was Sie also bei jeder Neuentwicklung tun, ist, einen Unit-Test zu schreiben - selbst wenn Sie keine einzige Klasse zu testen haben.

Überlegen Sie, was Sie testen wollen. Führen Sie nun den Test durch. Warum sollte er nicht kompilieren? Weil du classA brauchst. Erstellen Sie die Klasse und führen Sie den Test aus. Warum lässt er sich nicht kompilieren? Weil sie die MethodeA nicht hat. Schreiben Sie eine Methode und führen Sie den Unit-Test erneut aus. Warum schlägt der Test fehl? Weil MethodeA nicht implementiert ist. Implementieren Sie MethodeA und führen Sie den Test aus. Warum schlägt er fehl? Weil MethodeA nicht den richtigen erwarteten Wert zurückgibt...usw.

Wenn Sie so weitermachen und während der Entwicklung Unit-Tests schreiben, wird der Test schließlich erfolgreich sein und die Funktionalität ist vollständig.

Answer 4

Weiterführend zu Steve Freemans Antwort: Das Buch von Dave Astel heißt "Test-driven Development - A practical guide". Wenn es sich bei der Anwendung, die Sie schreiben, um eine GUI-Anwendung handelt, sollte dies hilfreich sein. Ich habe das Buch von Kent Becks gelesen, aber ich konnte nicht herausfinden, wie man ein Projekt mit TDD beginnt. Astels Buch testet eine komplette nicht-triviale GUI-Anwendung von Anfang bis Ende mit Hilfe von Stories. Es hat mir sehr geholfen, tatsächlich mit TDD zu beginnen, es hat mir gezeigt, wo und wie ich anfangen kann.

Answer 5

Testgetriebene Entwicklung kann für Anfänger verwirrend sein. Viele Bücher, die ich las, als ich TDD lernte, lehrten einen, wie man Unit-Tests für eine Rechnerklasse schreibt, aber es scheint sehr wenig Hilfe für die Erstellung von Anwendungen in der realen Welt zu geben, die eher datenzentriert sind, wenn ich es wage zu sagen. Für mich war der Durchbruch, als ich verstand, was Behaviour Driven Development oder BDD ist und wie man mit dem Testen von außen nach innen beginnt. Jetzt kann ich Ihnen nur raten, sich auf das Verhalten Ihrer Anwendung zu konzentrieren und Unit-Tests zu schreiben, um es zu verifizieren. Es wird viel über TDD und BDD diskutiert, aber ich denke, dass gut geschriebene automatisierte Tests auf jeder Ebene einen Mehrwert bieten, und um sie zu schreiben, müssen wir uns auf das Verhalten konzentrieren.

Hadi Hariri hat hier einen ausgezeichneten Beitrag http://hadihariri.com/2012/04/11/what-bdd-has-taught-me/

Ich habe auch einige Artikel zu diesem Thema geschrieben, die meines Erachtens zum Verständnis aller Konzepte im Zusammenhang mit TDD beitragen werden

http://codecooked.com/introduction-to-unit-testing-and-test-driven-development/

http://codecooked.com/different-types-of-tests-and-which-ones-to-use/