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

Es ist einfacher, als Sie denken. Sie verwenden einfach TDD für jede einzelne Klasse. Jede öffentliche Methode, die Sie in der Klasse haben, sollte auf alle möglichen Ergebnisse getestet werden. Die "Proof of Concept" TDD-Beispiele, die Sie sehen, können also auch in einer relativ großen Anwendung verwendet werden, die viele Hunderte von Klassen hat.

Eine weitere TDD-Strategie, die Sie verwenden können, ist die Simulation von Anwendungstestläufen selbst, indem Sie das Hauptverhalten der Anwendung kapseln. Ich habe zum Beispiel ein Framework geschrieben (in C++, aber das sollte für jede OO-Sprache gelten), das eine Anwendung darstellt. Es gibt abstrakte Klassen für die Initialisierung, die Hauptlaufschleife und das Beenden der Anwendung. Meine main()-Methode sieht also etwa so aus:

int main(int argc, char *argv[]) {
  int result = 0;

  myApp &mw = getApp(); // Singleton method to return main app instance
  if(mw.initialize(argc, argv) == kErrorNone) {
    result = mw.run();
  }

  mw.shutdown();
  return(result);
}

Dies hat einen doppelten Vorteil. Erstens kann die gesamte Funktionalität der Hauptanwendung in eine statische Bibliothek kompiliert werden, die dann sowohl mit der Testsuite als auch mit dieser main.cpp Stub-Datei gelinkt wird. Zweitens bedeutet es, dass ich ganze "Durchläufe" der Hauptanwendung simulieren kann, indem ich Arrays für argc & argv[] erstelle und dann simuliere, was in main() passieren würde. Wir verwenden diesen Prozess, um viele Funktionen aus der realen Welt zu testen, um sicherzustellen, dass die Anwendung genau das erzeugt, was sie angesichts eines bestimmten Korpus von Eingabedaten und Befehlszeilenargumenten aus der realen Welt tun soll.

Jetzt fragen Sie sich wahrscheinlich, wie sich dies bei einer Anwendung mit einer echten grafischen Benutzeroberfläche, einer webbasierten Schnittstelle oder was auch immer ändern würde. Dazu würde ich einfach sagen, dass man diese Aspekte des Programms mit Hilfe von Mock-ups testen sollte.

Aber kurz gesagt, mein Ratschlag lautet: Brechen Sie Ihre Testfälle auf die kleinste Ebene herunter und beginnen Sie dann, nach oben zu schauen. Schließlich wird die Testsuite sie alle zusammenwerfen, und Sie werden am Ende ein vernünftiges Maß an automatisierter Testabdeckung haben.

Answer 2

Ich hatte früher das gleiche Problem. Zu Beginn der Entwicklung habe ich meist einen Window-Designer gestartet, um die Benutzeroberfläche für die erste Funktion zu erstellen, die ich implementieren wollte. Da die Benutzeroberfläche eines der am schwierigsten zu testenden Dinge ist, lässt sich diese Arbeitsweise nicht sehr gut auf TDD übertragen.

Ich fand die Papiere über atomare Objekte auf Presenter First sehr hilfreich. Ich beginne immer noch mit der Vorstellung von Benutzeraktionen, die ich implementieren möchte (wenn Sie Usecases haben, ist das ein guter Anfang), und mit einem MVP- oder MVC-ähnlichen Modell beginne ich mit dem Schreiben eines Tests für den Presenter des ersten Bildschirms. Durch das Mocking der Ansicht, bis der Präsentator funktioniert, kann ich auf diese Weise sehr schnell beginnen. http://www.atomicobject.com/pages/Presenter+First Hier finden Sie weitere Informationen über diese Arbeitsweise.

Wenn Sie ein Projekt in einer Ihnen unbekannten Sprache oder einem Ihnen unbekannten Framework beginnen, können Sie zunächst einen Spike erstellen. Ich schreibe oft auch Unit-Tests für meine Spikes, aber nur, um den Code auszuführen, den ich spike. Der Spike kann Ihnen einige Anregungen geben, wie Sie Ihr richtiges Projekt beginnen können. Vergessen Sie nicht, Ihren Spike wegzuwerfen, wenn Sie mit Ihrem richtigen Projekt beginnen.

Answer 3

Ich beginne damit, an die Anforderungen zu denken.

foreach UseCase

1. UseCase analysieren
2. an zukünftige Klassen denken
3. Testfälle aufschreiben
4. Tests schreiben
5. Testen und Implementieren von Klassen (manchmal Hinzufügen neuer Tests, wenn ich unter Punkt 4 etwas übersehen habe).

Das war's. Es ist ziemlich einfach, aber ich denke, es ist zeitaufwendig. Mir gefällt es aber und ich halte mich daran :)

Wenn ich mehr Zeit habe, versuche ich, einige sequentielle Diagramme in Enterprise Architect zu modellieren.

Answer 4

Ich stimme zu, dass es besonders schwierig ist, den Prozess zu starten.

Normalerweise versuche ich, mir den ersten Satz von Tests wie ein Drehbuch vorzustellen, und vielleicht nur die erste Szene des Films.

Akteur1 sagt Akteur2, die Welt sei in Schwierigkeiten ist, Akteur2 gibt ein Paket, Akteur1 packt das Paket aus, usw.

Das ist natürlich ein seltsames Beispiel, aber ich finde, dass die Visualisierung der Wechselwirkungen oft eine gute Möglichkeit ist, die anfängliche Schwierigkeit zu überwinden. Es gibt andere analoge Techniken (User Stories, RRC-Karten usw.), die sich gut für größere Gruppen eignen, aber es klingt so, als wären Sie allein und bräuchten den zusätzlichen Overhead nicht.

Außerdem bin ich mir sicher, dass es das Letzte ist, was Sie tun wollen, ein weiteres Buch zu lesen, aber die Jungs von MockObjects.com haben ein Buch im frühen Entwurfsstadium, derzeit mit dem Titel Wachsende objektorientierte Software, geleitet von Tests . Die Kapitel, die derzeit zur Überprüfung anstehen, können Ihnen einen weiteren Einblick geben, wie Sie TDD beginnen und fortführen können.

Answer 5

Das Problem ist, dass Sie auf Ihre Tastatur schauen und sich fragen, welche Tests Sie schreiben müssen.

Denken Sie stattdessen an den Code, den Sie schreiben wollen, suchen Sie dann den ersten kleinen Teil dieses Codes, und versuchen Sie dann, sich den Test auszudenken, der Sie zwingen würde, dieses kleine Stück Code zu schreiben.

Am Anfang hilft es, die Arbeit in sehr kleine Stücke. Sogar im Laufe eines einzigen Tages werden Sie in größeren Stücken arbeiten. Aber immer, wenn Sie nicht weiterkommen, denken Sie einfach an das kleinste Stück Code, das Sie als nächstes schreiben wollen, und schreiben Sie dann den Test dafür.