Wie macht man TDD in einer nicht-trivialen Anwendung?

Question

Ich habe eine Reihe von Büchern und Websites zum Thema TDD gelesen, und sie machen alle sehr viel Sinn, insbesondere das Buch von Kent Beck. Wenn ich jedoch versuche, TDD selbst durchzuführen, starre ich immer auf die Tastatur und frage mich, wie ich anfangen soll. Gibt es einen Prozess, den Sie verwenden? Was ist Ihr Gedankenprozess? Wie identifizieren Sie Ihre ersten Tests?

In den meisten Büchern zu diesem Thema wird sehr gut beschrieben, was TDD ist, aber nicht, wie man es umsetzt. Praxis TDD in realen, nicht-trivialen Anwendungen. Wie führen Sie TDD durch?

Answer 1

Ich glaube nicht, dass Sie wirklich mit TDD beginnen sollten. Ernsthaft, wo sind Ihre Spezifikationen? Haben Sie sich schon auf einen allgemeinen/groben Gesamtentwurf für Ihr System geeinigt, der puede für Ihre Anwendung geeignet sein? Ich weiß, TDD und agile entmutigt Big Design Up-Front, aber das bedeutet nicht, dass Sie nicht tun sollten, Design Up-Front zuerst vor TDDing Ihren Weg durch die Umsetzung dieses Designs.

Answer 2

Manchmal weiß man nicht, wie man TDD durchführen soll, weil der Code nicht "testfreundlich" (leicht testbar) ist.

Dank einiger guter Praktiken können Ihre Klassen einfacher isoliert getestet werden, um echte Unit-Tests zu erreichen.

Vor kurzem bin ich auf eine Blog von einem Google-Mitarbeiter, in dem beschrieben wird, wie Sie Ihre Klassen und Methoden so gestalten können, dass sie leichter zu testen sind.

Hier ist einer seiner jüngsten Vorträge die ich empfehle.

Er weist nachdrücklich darauf hin, dass man die Geschäftslogik vom Code für die Objekterzeugung trennen muss (d. h., dass man die Logik nicht mit dem "new"-Operator vermischen darf), indem man das Dependency Injection-Muster verwendet. Er erklärt auch, wie wichtig das Gesetz von Demeter für testbaren Code ist. Er konzentriert sich hauptsächlich auf Java-Code (und Guice ), aber seine Grundsätze sollten eigentlich für jede Sprache gelten.

Answer 3

Am einfachsten ist es, mit einer Klasse zu beginnen, die keine Abhängigkeiten hat, eine Klasse, die von anderen Klassen verwendet wird, aber keine andere Klasse verwendet. Dann sollte man sich einen Test vornehmen und sich fragen: "Wie kann ich wissen, ob diese Klasse (diese Methode) korrekt implementiert ist?".

Dann könnten Sie einen ersten Test schreiben, um Ihr Objekt abzufragen, wenn es nicht initialisiert ist, es könnte NULL zurückgeben, oder eine Ausnahme auslösen. Dann können Sie Ihr Objekt (vielleicht nur teilweise) initialisieren, und testen, ob es etwas Wertvolles zurückgibt. Dann können Sie einen Test mit einem anderen Initialisierungswert hinzufügen - dieser sollte sich genauso verhalten. Zu diesem Zeitpunkt teste ich normalerweise eine Fehlerbedingung - z. B. den Versuch, das Objekt mit einem ungültigen Wert zu initialisieren.

Wenn Sie mit der Methode fertig sind, wechseln Sie zu einer anderen Methode derselben Klasse, bis Sie mit der gesamten Klasse fertig sind.

Dann können Sie eine andere Klasse wählen - entweder eine andere unabhängige Klasse oder eine Klasse, die die erste Klasse, die Sie implementiert haben, verwendet.

Wenn Sie sich für eine Klasse entscheiden, die auf Ihrer ersten Klasse aufbaut, halte ich es für akzeptabel, dass Ihre Testumgebung - oder Ihre zweite Klasse - die erste Klasse instanziiert, da sie vollständig getestet wurde. Wenn ein Test der Klasse fehlschlägt, sollten Sie in der Lage sein, festzustellen, in welcher Klasse das Problem liegt.

Sollten Sie in der ersten Klasse ein Problem entdecken oder sich fragen, ob sie sich unter bestimmten Bedingungen korrekt verhält, dann schreiben Sie einen neuen Test.

Wenn Sie beim Klettern durch die Abhängigkeiten feststellen, dass die Tests, die Sie schreiben, sich über zu viele Klassen erstrecken, um als Unit-Tests zu gelten, können Sie ein Mock-Objekt verwenden, um eine Klasse vom Rest des Systems zu isolieren.

---

Wenn Sie bereits Ihren Entwurf haben - wie Sie in einem Kommentar in der Antwort von Jon LimJap angedeutet haben, dann tun Sie nicht reines TDD, da es bei TDD darum geht, Einheitstests zu verwenden, um Ihren Entwurf entstehen zu lassen.

Abgesehen davon erlauben nicht alle Geschäfte striktes TDD, und Sie haben ein Design zur Hand, also lassen Sie es uns verwenden und TDD machen - obwohl es besser wäre, Test-First-Programming zu sagen, aber das ist nicht der Punkt, denn so habe ich auch mit TDD angefangen.