Angenommen, ich habe eine Reihe von User Stories (aufgrund der Planungssitzung habe ich mein Team durchlaufen). Ich habe noch keinen Code in der Anwendung und werde mit meinem 'A' beginnen oder höchste Priorität Geschichten / Epics
Sagen Sie zum Beispiel
" Als ein Benutzer sollte ich in der Lage sein, nach mehr Benutzern zu suchen, damit ich mehr Freunde auf der Website hinzufügen kann "
Wie sollte das Team also während der TDD die Anwendung programmieren?
Team beginnt mit dem Erstellen von Komponententests, dh, die sich um das Erstellen von Modellen kümmern
Dann nimmt jeder eine Geschichte und beginnt mit dem Schreiben von Funktionstests, um meine Controller / Views zu erstellen (also sollten sie Integrationstests durchführen, während sie Funktionstests schreiben)
Dann machen Sie die Integrationstests
Ich bin eigentlich verwirrt, wie die Integrationstests passen. Wenn alle Integrationstests funktionieren (dh alle funktionalen Unit-Tests sollten sowieso bestehen)
Also, wenn die Anwendung gerade startet (dh noch kein Code geschrieben wurde). Was ist der Prozess, den Leute normalerweise für TDD / BDD nehmen, wenn sie eine Story aufgreifen und damit beginnen, eine Anwendung von Grund auf zu implementieren?
"Ich bin tatsächlich verwirrt, wie die Integrationstests passen. Wenn alle Integrationstests funktionieren (dh alle funktionalen Unit-Tests sollten trotzdem bestehen) "
Es kommt darauf an. Sicher, es ist möglich, Integrationstests so zu schreiben, dass alle Unit- und Funktionstests bestanden werden. Es ist einfach viel schwieriger.
Stellen Sie sich vor, Sie haben 3 Modelle, 3 Controller und 3 Ansichten. Stellen Sie sich vor, alle sind sehr einfach ohne Bedingungen oder Schleifen und haben jeweils eine Methode.
Sie können nun jede dieser Einheiten für insgesamt 9 Assertionen testen und vollständig abdecken. Sie können einen Integrationstest einwerfen, um sicherzustellen, dass all diese Dinge gut zusammen funktionieren.
Wenn Sie stattdessen Einheiten / Funktionale überspringen und eine vollständige Abdeckung benötigen, benötigen Sie 27 Assertionen (3 x 3 x 3).
In der Praxis sind die Dinge natürlich komplizierter. Sie benötigen eine viel größere Anzahl von Integrationstests, um auf die gleiche Abdeckungsebene zu gelangen.
Auch, wenn Sie TDD / BDD üben, wird es meistens mit vielen Unit-Tests enden. Der Integrationstest soll sicherstellen, dass alle Teile gut zusammenpassen und tun, was der Kunde möchte. Die Stücke selbst wurden einzeln durch die Unit Tests getestet.
Sehr gute Frage! Der TDD / BDD-Weg würde vorschlagen, dass Sie die Benutzergeschichten nehmen und Validierungspunkte schreiben (lesen Sie Hochstufentests). Sie verwenden GWT (Gegeben / Wann / Dann) wie folgt sprechen.
"Als ein Benutzer sollte ich in der Lage sein, nach mehr Benutzern zu suchen, damit ich mehr Freunde auf der Website hinzufügen kann"
%Vor%Dies ist Ihr erstes Feedback und die erste Möglichkeit, mit dem Product Owner zu iterieren. Stellen Sie Fragen, wie sollte die Suchleiste gehen? Sollte es automatisch abgeschlossen werden? Als nächstes weisen Sie den UI-Objekten "Verhalten" zu. Diese haben auch Validierungspunkte.
Dies würde das Verhalten der Suchschaltfläche definieren:
%Vor%Dies würde die Logik Ihrer Suche beschreiben:
%Vor%Der erste Validierungspunkt würde das Verhalten der Verknüpfung der Steuerungssuchschaltfläche mit einem beliebigen Modell, das den Suchalgorithmus implementiert, beschreiben. Der zweite Validierungspunkt beschreibt den Suchalgorithmus selbst. Der Vorteil ist, dass diese Teile unabhängig voneinander definiert sind und parallel entworfen werden können. Es gibt Ihnen auch eine nette API und kleine, leicht zu planende Features, um zu iterieren. Es gibt Ihnen auch die Möglichkeit, auf jedem Teil des Puzzles zu iterieren / verfeinern, ohne den Rest des Kuchens zu beeinflussen.
Update Ich möchte auch erwähnen, dass das, was ich als Validierungspunkte bezeichne, locker mit UATs oder User Acceptance Tests in Verbindung gebracht werden kann. Bleib nicht auf den Bedingungen hängen, weil sie irrelevant sind. Konzentriere dich auf die Idee dahinter. Sie müssen die User Story nehmen und in Spezifikationen zerlegen. (kann in einem oder mehreren Pässen mit UATs oder Validierungspunkten oder beiden oder Magic Beans getan werden, stellen Sie sicher, dass Sie sie brechen.) Wenn Sie Ihre User Stories gebrochen haben, können sie in einem Tool wie FitNesse, JUnit oder geschrieben werden RSpec benutzt dann eines dieser Tools, ansonsten brauchst du entweder weitere Konversation (Sind deine User Stories zu vage?) Oder einen anderen Durchlauf darüber, was du weiter abbauen musst (UATs zu Validierungspunkten). Besorgt euch nicht um die Werkzeuge und fühlt, als müsstest ihr alles von Anfang an automatisieren. Lassen Sie Selenium in Ruhe, bis Sie den manuellen Prozess beenden. Schließlich möchten Sie Spezifikationen, die in programmatischen testartigen Form zu diesem Zeitpunkt geschrieben werden können, sollten Sie in der Lage sein, etwas so einfaches wie JUnit zu verwenden, um mit dem Programmieren zu beginnen. Wenn Sie besser / schicker werden, können Sie EasyB oder RSpec Story Runner und andere Dinge aufgreifen.
Dies ist, wo wir normalerweise mit einem Sprint 0 beginnen und in diesem Frühling ist, wo wir haben, was XP-Aufruf eine Spike-Sitzung ist (oder eine Wegwerf-Code-Sitzung). In dieser Sitzung können Sie mit dem Prototyping beginnen.
Schreiben Sie in Ihrer Sitzung einige Benutzerakzeptanztests (vorzugsweise im BDD-Format) und beginnen Sie dann, einen Test zu schreiben, der zuerst mit einem Ihrer UATs übereinstimmt.
Zum Beispiel:
Gegeben ist eine Suche angefordert wo der Benutzername "testUser" ist 1 Ergebnis sollte zurückgegeben werden.
Damit hast du jetzt ein Ziel für deinen ersten Test, den du schreibst, dann beginnst du Code zu schreiben, um diesen Test bestanden zu haben. Während du vorwärts gehst, solltest du anfangen zu sehen, wie die App zusammengesetzt werden sollte, um die Geschichte zu vervollständigen.
Dann würde ich in den nächsten Sprint-Build Stories / Tasks beginnen, um das Feature nach Bedarf zu vervollständigen, basierend auf dem, was Sie im Sprint 0 entdeckt haben.
Zerschneide zuerst die Geschichte. Du brauchst:
Jetzt haben Sie das Modell. Als nächstes machen Sie das gleiche für die Controller. Wenn sie arbeiten, beginnen Sie mit den Ansichten.
Wenn Sie ein Profi sind und dies bereits tausend Mal getan haben, können Sie möglicherweise mehrere Schritte gleichzeitig durchführen.
Aber Sie müssen zuerst das Problem in verdauliche Stücke hacken.
Weiter für die Integrationstests. Sie werden simulieren, was ein Benutzer tut. Im allgemeinen Fall müssen Sie eine Reihe von Komponententests schreiben (sie werden nur Integrationstests genannt, sollten aber auch automatisch ausgeführt werden können). Diese Tests müssen genau wie der Benutzer mit der Web-App kommunizieren. Daher benötigen Sie einen simulierten Web-Browser usw.
Sie können Ссылка oder env ausprobieren .js dafür.
Wenn Sie TDD ausführen, beginnen Sie mit einem Test, der zeigt, dass das -System nicht das von der User Story beschriebene Verhalten ausführt. Wenn dies mit der erwarteten Diagnose fehlschlägt, beginnen Sie mit nützlichen Diagnosen, das Verhalten durch Hinzufügen oder Ändern von Klassen zu implementieren, indem Sie zunächst den Einheitentest testen.
In TDD schreiben Sie also Integrationstests, bevor Sie Komponententests schreiben.
Um den gesamten Prozess zu starten, schreibt man normalerweise ein "gehendes Skelett": ein System, das den dünnsten Teil der realistischen Funktionalität ermöglicht. Mit dem Laufskelett bauen wir die Integrationstest-Infrastruktur gegen einfache Funktionalität auf.
Der Rest des Projekts füllt dann dieses Skelett aus.