Reicht es aus, Akzeptanz- und Integrationstests anstelle von Komponententests zu verwenden?

Kurze Einführung in diese Frage. Ich benutze jetzt TDD und in letzter Zeit BDD seit über einem Jahr. Ich benutze Techniken wie das Verspotten, um meine Tests effizienter zu schreiben. In letzter Zeit habe ich ein persönliches Projekt gestartet, um ein kleines Money-Management-Programm für mich zu schreiben. Da ich keinen alten Code hatte, war es das perfekte Projekt, um mit TDD zu beginnen. Leider habe ich die Freude an TDD nicht so sehr erlebt. Es hat sogar meinen Spaß so sehr verdorben, dass ich das Projekt aufgegeben habe.

Was war das Problem? Nun, ich habe den TDD-ähnlichen Ansatz verwendet, um die Tests / Anforderungen das Design des Programms weiterentwickeln zu lassen. Das Problem war, dass mehr als die Hälfte der Entwicklungszeit für das Schreiben / Refactor-Tests. Am Ende wollte ich keine Features mehr implementieren, da ich viele Tests überarbeiten und schreiben musste.

Bei der Arbeit habe ich viel Legacy-Code. Hier schreibe ich immer mehr Integrations- und Akzeptanztests und weniger Unit-Tests. Dies scheint kein schlechter Ansatz zu sein, da Fehler meist durch Akzeptanz- und Integrationstests erkannt werden.

Meine Idee war, dass ich am Ende mehr Integrations- und Akzeptanztests schreiben könnte als Unit-Tests. Wie ich bereits sagte, sind die Komponententests zur Erkennung von Fehlern nicht besser als die Integrations- / Abnahmetests. Unit-Test sind auch gut für das Design. Da ich viele von ihnen geschrieben habe, sind meine Klassen immer so gestaltet, dass sie gut testbar sind. Darüber hinaus führt der Ansatz, dass die Tests / Anforderungen das Design leiten, in den meisten Fällen zu einem besseren Design. Der letzte Vorteil von Unit-Tests ist, dass sie schneller sind. Ich habe genug Integrationstests geschrieben, um zu wissen, dass sie fast so schnell sein können wie die Unit-Tests.

Nachdem ich das Web durchgesehen hatte, stellte ich fest, dass es sehr ähnliche Ideen zu meinen gibt, die hier und da erwähnt werden . Was haltet ihr von dieser Idee?

Bearbeiten

Als ich auf die Fragen eines Beispiels antwortete, in dem das Design gut war, brauchte ich ein großes Refactoring für die nächste Anforderung:

Zuerst gab es einige Anforderungen, um bestimmte Befehle auszuführen. Ich habe einen erweiterbaren Befehlsparser geschrieben, der Befehle von einer Eingabeaufforderung aus analysierte und den richtigen Befehl für das Modell aufrief. Das Ergebnis wurde in einer Ansichtsmodellklasse dargestellt:

Hier war nichts falsch. Alle Klassen waren unabhängig voneinander und ich konnte leicht neue Befehle hinzufügen, neue Daten anzeigen.

Die nächste Anforderung war, dass jeder Befehl eine eigene Ansichtsdarstellung haben sollte - eine Art Vorschau des Befehlsergebnisses. Ich habe das Programm überarbeitet, um ein besseres Design für die neue Anforderung zu erzielen:

Das war auch gut so, denn jetzt hat jeder Befehl ein eigenes Ansichtsmodell und damit eine eigene Vorschau.

Die Sache ist, dass der Befehlsparser geändert wurde, um ein Token-basiertes Parsen der Befehle zu verwenden, und seine Fähigkeit, die Befehle auszuführen, wurde gestrippt. Jeder Befehl hat ein eigenes Ansichtsmodell, und das Datenansichtsmodell kennt nur das aktuelle Befehlsansichtsmodell, das dann die anzuzeigenden Daten kennt.

Ich wollte an dieser Stelle nur wissen, ob das neue Design keine bestehenden Anforderungen erfüllt. Ich musste keinen meiner Abnahmetests ändern. Ich musste fast JEDEN Komponententest überarbeiten oder löschen, was einen riesigen Haufen Arbeit darstellte.

Was ich hier zeigen wollte, ist eine häufige Situation, die während der Entwicklung häufig vorkam. Es gab kein Problem mit dem alten oder dem neuen Design, sie änderten sich einfach auf natürliche Weise mit den Anforderungen - wie ich es verstanden habe, ist dies ein Vorteil von TDD, dass sich das Design weiterentwickelt.

Fazit

Vielen Dank für alle Antworten und Diskussionen. Als Zusammenfassung dieser Diskussion habe ich mir einen Ansatz überlegt, den ich bei meinem nächsten Projekt testen werde.

• Zunächst schreibe ich alle Tests, bevor ich etwas implementiere, wie ich es immer getan habe.
• Für Anforderungen schreibe ich zunächst einige Abnahmetests, die das gesamte Programm testen. Dann schreibe ich einige Integrationstests für die Komponenten, in denen ich die Anforderung implementieren muss. Wenn es eine Komponente gibt, die eng mit einer anderen Komponente zusammenarbeitet, um diese Anforderung umzusetzen, würde ich auch einige Integrationstests schreiben, bei denen beide Komponenten zusammen getestet werden. Last but not least würde ich Unit-Tests für diese bestimmte Klasse schreiben, wenn ich einen Algorithmus oder eine andere Klasse mit hoher Permutation schreiben müsste, z. B. einen Serializer. Alle anderen Klassen werden nicht getestet, es werden jedoch Unit-Tests durchgeführt.
• Bei Fehlern kann der Prozess vereinfacht werden. Normalerweise wird ein Fehler durch eine oder zwei Komponenten verursacht. In diesem Fall würde ich einen Integrationstest für die Komponenten schreiben, der den Fehler testet. Wenn es sich um einen Algorithmus handeln würde, würde ich nur einen Komponententest schreiben. Wenn es nicht einfach ist, die Komponente zu erkennen, in der der Fehler auftritt, würde ich einen Akzeptanztest schreiben, um den Fehler zu lokalisieren - dies sollte eine Ausnahme sein.

Es vergleicht Orangen und Äpfel.

Integrationstests, Abnahmetests, Komponententests, Verhaltenstests - das sind alles Tests, die Ihnen bei der Verbesserung Ihres Codes helfen, aber auch ganz andere.

Ich gehe meiner Meinung nach jeden der verschiedenen Tests durch und erkläre hoffentlich, warum Sie eine Mischung aus allen benötigen:

Integrationstests:

Testen Sie einfach, ob verschiedene Komponenten Ihres Systems korrekt integriert sind - beispielsweise simulieren Sie eine Webservice-Anfrage und überprüfen Sie, ob das Ergebnis zurückkommt. Ich würde im Allgemeinen reale (ish) statische Daten und verspottete Abhängigkeiten verwenden, um sicherzustellen, dass diese konsistent überprüft werden können.

Akzeptanztests:

Ein Akzeptanztest sollte direkt mit einem Geschäftsanwendungsfall korrelieren. Es kann riesig sein ("Trades werden korrekt übermittelt") oder winzig ("Filter filtert eine Liste erfolgreich") - es spielt keine Rolle; Was zählt, ist, dass es explizit an eine bestimmte Benutzeranforderung gebunden sein sollte. Ich konzentriere mich gerne auf diese für die testgetriebene Entwicklung, da dies bedeutet, dass wir ein gutes Referenzhandbuch mit Tests für User Stories haben, die von dev und qa überprüft werden müssen.

Unit-Tests:

Für kleine diskrete Funktionseinheiten, die für sich genommen eine einzelne User Story bilden können oder nicht, kann eine User Story, die besagt, dass wir alle Kunden abrufen, wenn wir auf eine bestimmte Webseite zugreifen, ein Akzeptanztest sein (simulieren Sie das Aufrufen des Webs) Seite und Überprüfung der Antwort), kann jedoch auch mehrere Komponententests enthalten (überprüfen Sie, ob die Sicherheitsberechtigungen überprüft wurden, ob die Datenbankverbindung korrekt abgefragt wurde, ob Code, der die Anzahl der Ergebnisse einschränkt, korrekt ausgeführt wurde) - dies sind alles "Komponententests". Das ist kein vollständiger Abnahmetest.

Verhaltenstests:

Definieren Sie, wie der Ablauf einer Anwendung bei einer bestimmten Eingabe aussehen soll. Beispiel: "Wenn keine Verbindung hergestellt werden kann, überprüfen Sie, ob das System die Verbindung erneut versucht." Auch hier ist es unwahrscheinlich, dass dies ein vollständiger Abnahmetest ist, aber Sie können trotzdem etwas Nützliches überprüfen.

Diese sind meiner Meinung nach alle durch viel Erfahrung im Schreiben von Tests entstanden; Ich mag es nicht, mich auf die Lehrbuchansätze zu konzentrieren, sondern auf das, was Ihren Tests Wert verleiht.

TL; DR: Solange es Ihren Bedürfnissen entspricht, ja.

Ich mache seit vielen Jahren die Entwicklung von Acceptance Test Driven Development (ATDD). Es kann sehr erfolgreich sein. Es gibt ein paar Dinge zu beachten.

• Unit-Tests helfen wirklich dabei, das IOC durchzusetzen. Ohne Unit-Tests müssen die Entwickler sicherstellen, dass sie die Anforderungen an gut geschriebenen Code erfüllen (sofern Unit-Tests gut geschriebenen Code enthalten).
• Sie können langsamer sein und falsche Fehler aufweisen, wenn Sie tatsächlich Ressourcen verwenden, die normalerweise verspottet sind.
• Bei dem Test wird das spezifische Problem nicht genau wie bei Unit-Tests ermittelt. Sie müssen weitere Untersuchungen durchführen, um Testfehler zu beheben.

Nun die Vorteile

• Viel bessere Testabdeckung, deckt Integrationspunkte ab.
• Gewährleistet, dass das System als Ganzes die Akzeptanzkriterien erfüllt, worum es bei der Softwareentwicklung geht.
• Erleichtert, beschleunigt und verbilligt große Refaktoren.

Wie immer liegt es an Ihnen, die Analyse durchzuführen und herauszufinden, ob diese Praxis für Ihre Situation geeignet ist. Im Gegensatz zu vielen Menschen glaube ich nicht, dass es eine idealisierte richtige Antwort gibt. Dies hängt von Ihren Bedürfnissen und Anforderungen ab.

Nun, ich habe den TDD-ähnlichen Ansatz verwendet, um die Tests / Anforderungen das Design des Programms weiterentwickeln zu lassen. Das Problem war, dass mehr als die Hälfte der Entwicklungszeit für das Schreiben / Refactor-Tests

Unit-Tests funktionieren am besten, wenn sich die öffentliche Schnittstelle der Komponenten, für die sie verwendet werden, nicht zu oft ändert. Das heißt, wenn die Komponenten bereits gut konstruiert sind (z. B. nach den SOLID-Grundsätzen).

Zu glauben, dass ein gutes Design nur durch das "Werfen" vieler Komponententests entsteht, ist ein Trugschluss. TDD ist kein "Lehrer" für gutes Design, es kann nur ein bisschen helfen, um zu überprüfen, ob bestimmte Aspekte des Designs gut sind (insbesondere die Testbarkeit).

Wenn sich Ihre Anforderungen ändern und Sie die Interna einer Komponente ändern müssen und dies 90% Ihrer Komponententests zum Erliegen bringt, müssen Sie diese sehr oft überarbeiten, dann war das Design höchstwahrscheinlich nicht so gut.

Mein Rat lautet daher: Überlegen Sie sich, wie Sie die von Ihnen erstellten Komponenten konstruktiv gestalten und wie Sie sie nach dem Open / Closed-Prinzip weiterentwickeln können. Letzteres soll sicherstellen, dass die Funktionalität Ihrer Komponenten später erweitert werden kann, ohne sie zu ändern (und damit die von Ihren Komponententests verwendete API nicht beeinträchtigt). Solche Komponenten können (und sollten) durch Unit-Test-Tests abgedeckt werden, und die Erfahrung sollte nicht so schmerzhaft sein, wie Sie es beschrieben haben.

Wenn Sie ein solches Design nicht sofort entwickeln können, sind Akzeptanz- und Integrationstests in der Tat ein besserer Anfang.

BEARBEITEN: Manchmal ist das Design Ihrer Komponenten in Ordnung, aber das Design Ihrer Komponententests kann Probleme verursachen . Einfaches Beispiel: Sie wollen die Methode "MyMethod" der Klasse X testen und schreiben

    var x= new X();
    Assert.AreEqual("expected value 1" x.MyMethod("value 1"));
    Assert.AreEqual("expected value 2" x.MyMethod("value 2"));
    // ...
    Assert.AreEqual("expected value 500" x.MyMethod("value 500"));

(Nehmen wir an, die Werte haben irgendeine Bedeutung).

Nehmen wir weiter an, dass es im Produktionscode nur einen Aufruf von gibt X.MyMethod. Für eine neue Anforderung benötigt die Methode "MyMethod" einen zusätzlichen Parameter (zum Beispiel so etwas wie context), der nicht weggelassen werden kann. Ohne Unit-Tests müsste man den aufrufenden Code an nur einer Stelle umgestalten. Bei Unit-Tests muss man 500 Stellen umgestalten.

Die Ursache ist jedoch nicht, dass das Gerät sich selbst testet, sondern dass derselbe Aufruf von "X.MyMethod" immer wieder wiederholt wird und nicht unbedingt dem Prinzip "Don't Repeat Yourself (DRY)" folgt Hier müssen Sie die Testdaten und die zugehörigen erwarteten Werte in eine Liste aufnehmen und die Aufrufe von "MyMethod" in einer Schleife ausführen (oder, wenn das Testtool sogenannte "Datenlaufwerktests" unterstützt, diese Funktion verwenden) Die Anzahl der Stellen, die in den Unit-Tests geändert werden sollen, wenn die Methodensignatur auf 1 geändert wird (im Gegensatz zu 500).

In Ihrem realen Fall mag die Situation komplexer sein, aber ich hoffe, Sie haben eine Idee: Wenn Ihre Komponententests eine Komponenten-API verwenden, für die Sie nicht wissen, ob Änderungen möglich sind, sollten Sie die Anzahl reduzieren von Aufrufen an diese API auf ein Minimum.

Ja, natürlich ist es das.

Bedenken Sie:

• Ein Unit-Test ist ein kleiner, gezielter Test, der einen kleinen Code ausführt. Sie schreiben viele davon, um eine anständige Codeabdeckung zu erzielen, sodass alle (oder die Mehrzahl der umständlichen Bits) getestet werden.
• Ein Integrationstest ist ein umfangreicher Test, der eine große Oberfläche Ihres Codes testet. Sie schreiben nur wenige davon, um eine angemessene Codeabdeckung zu erzielen, sodass alle (oder die meisten der umständlichen Bits) getestet werden.

Sehen Sie den allgemeinen Unterschied ...

Das Problem ist die Codeabdeckung. Wenn Sie mithilfe von Integrations- / Akzeptanztests einen vollständigen Test Ihres gesamten Codes durchführen können, gibt es kein Problem. Ihr Code wird getestet. Das ist das Ziel.

Ich denke, Sie müssen sie möglicherweise verwechseln, da jedes TDD-basierte Projekt einige Integrationstests erfordert, um sicherzustellen, dass alle Einheiten tatsächlich gut zusammenarbeiten (ich weiß aus Erfahrung, dass eine zu 100% bestandene, auf Einheiten getestete Codebasis nicht unbedingt funktioniert wenn du sie alle zusammenstellst!)

Das Problem besteht darin, dass das Testen, Debuggen und Beheben von Fehlern sehr einfach ist. Einige Leute finden, dass ihre Komponententests sehr gut sind, sie sind klein und einfach und Fehler sind leicht zu erkennen, aber der Nachteil ist, dass Sie Ihren Code neu organisieren müssen, um ihn an die Komponententest-Tools anzupassen, und sehr viele von ihnen schreiben müssen. Es ist schwieriger, einen Integrationstest zu schreiben, um eine Menge Code abzudecken, und Sie müssen wahrscheinlich Techniken wie die Protokollierung verwenden, um Fehler zu debuggen (obwohl Sie dies sowieso tun müssen, können Sie keine Unit-Test-Fehler durchführen wenn vor Ort!).

In beiden Fällen erhalten Sie immer noch getesteten Code. Sie müssen nur entscheiden, welcher Mechanismus besser zu Ihnen passt. (Ich würde ein bisschen mischen, die komplexen Algorithmen testen und den Rest integrieren).

Ich halte das für eine schreckliche Idee.

Da Akzeptanztests und Integrationstests größere Teile Ihres Codes berühren, um ein bestimmtes Ziel zu testen, müssen sie im Laufe der Zeit mehr und nicht weniger überarbeitet werden. Schlimmer noch, da sie weite Teile des Codes abdecken, verbringen Sie mehr Zeit damit, die eigentliche Ursache aufzuspüren, da Sie einen breiteren Suchbereich haben.

Nein, Sie sollten normalerweise mehr Komponententests schreiben, es sei denn, Sie haben eine App mit 90% Benutzeroberfläche oder etwas anderes, das für Komponententests umständlich ist. Der Schmerz, auf den Sie stoßen, stammt nicht aus Unit-Tests, sondern aus der ersten Testentwicklung. Im Allgemeinen sollten Sie höchstens 1/3 Ihrer Zeit damit verbringen, Tests zu schreiben. Schließlich sind sie da, um Ihnen zu dienen, nicht umgekehrt.

Der "Gewinn" bei TDD ist, dass sobald die Tests geschrieben wurden, sie automatisiert werden können. Die Kehrseite ist, dass es einen erheblichen Teil der Entwicklungszeit verbrauchen kann. Ob dies den gesamten Prozess tatsächlich verlangsamt, ist umstritten. Das Argument ist, dass das Vorab-Testen die Anzahl der Fehler reduziert, die am Ende des Entwicklungszyklus behoben werden müssen.

Hier kommt BDD ins Spiel, da Verhaltensweisen in den Unit-Test einbezogen werden können, sodass der Prozess per Definition weniger abstrakt und greifbarer ist.

Wenn unendlich viel Zeit zur Verfügung stünde, würden Sie natürlich so viele Tests verschiedener Sorten wie möglich durchführen. Die Zeit ist jedoch im Allgemeinen begrenzt und kontinuierliche Tests sind nur bis zu einem gewissen Punkt kosteneffektiv.

Dies alles führt zu dem Schluss, dass die Tests, die den höchsten Wert liefern, im Vordergrund des Prozesses stehen sollten. Dies an sich begünstigt nicht automatisch eine Art von Prüfung gegenüber einer anderen - vielmehr muss jeder Fall einzeln geprüft werden.

Wenn Sie ein Befehlszeilen-Widget für den persönlichen Gebrauch schreiben, interessieren Sie sich hauptsächlich für Komponententests. Während ein Web-Service sagen würde, würde eine erhebliche Menge an Integration / Verhaltenstests erfordern.

Während sich die meisten Arten von Tests auf das konzentrieren, was man als "Rennstrecke" bezeichnen könnte, dh zu testen, was das Unternehmen heute benötigt, sind Unit-Tests hervorragend geeignet, um subtile Fehler zu beseitigen, die in späteren Entwicklungsphasen auftauchen könnten. Da dies ein Vorteil ist, der nicht leicht zu messen ist, wird er häufig übersehen.

Der letzte Vorteil von Unit-Tests ist, dass sie schneller sind. Ich habe genug Integrationstests geschrieben, um zu wissen, dass sie fast so schnell sein können wie die Unit-Tests.

Dies ist der entscheidende Punkt und nicht nur "der letzte Vorteil". Wenn das Projekt immer größer wird, werden Ihre Integrationstests immer langsamer. Und hier meine ich so langsam, dass Sie aufhören werden, sie auszuführen.

Natürlich werden Unit-Tests auch langsamer, aber sie sind immer noch mehr als eine Größenordnung schneller. In meinem vorherigen Projekt (c ++, ungefähr 600 kLOC, 4000 Komponententests und 200 Integrationstests) dauerte es zum Beispiel ungefähr eine Minute, um alle und mehr als 15 auszuführen, um Integrationstests auszuführen. Das Erstellen und Ausführen von Komponententests für das zu ändernde Teil dauert im Durchschnitt weniger als 30 Sekunden. Wenn Sie es so schnell schaffen, wollen Sie es die ganze Zeit tun.

Nur um es klar zu machen: Ich sage nicht, Integrations- und Akzeptanztests hinzuzufügen, aber es sieht so aus, als hätten Sie TDD / BDD falsch gemacht.

Unit-Test sind auch gut für das Design.

Ja, wenn Sie die Testbarkeit berücksichtigen, wird das Design besser.

Das Problem war, dass mehr als die Hälfte der Entwicklungszeit für das Schreiben / Refactor-Tests. Am Ende wollte ich keine Features mehr implementieren, da ich viele Tests überarbeiten und schreiben musste.

Wenn sich die Anforderungen ändern, müssen Sie den Code ändern. Ich würde sagen, dass Sie Ihre Arbeit nicht beendet haben, wenn Sie keine Komponententests geschrieben haben. Das heißt aber nicht, dass Sie eine 100% ige Abdeckung mit Unit-Tests haben sollten - das ist nicht das Ziel. Einige Dinge (wie die Benutzeroberfläche oder der Zugriff auf eine Datei, ...) sind nicht einmal für den Unit-Test gedacht.

Das Ergebnis ist eine bessere Codequalität und eine weitere Testebene. Ich würde sagen, es lohnt sich.

Wir hatten auch mehrere 1000er-Abnahmetests und es würde eine ganze Woche dauern, bis alle durchgeführt waren.