Komponententests werden Integrationstests mit TDD

Question

Angenommen, ich schreibe eine Anwendung, die Test Driven Development verwendet. Alle Beispiele, die ich finde, sind sehr kleine Beispiele, die versuchen zu erklären, wie Tests in TDD geschrieben werden müssen.

Wenn Sie einen Test in TDD schreiben, schreiben Sie ein sehr kleines Stück Code, dessen Zweck es ist, ein einzelnes Stück Code zu testen, eine einzelne Methode, also einen Komponententest.

Nach einiger Zeit wird eine Anforderung vom Client empfangen, und Sie müssen Ihren ursprünglichen Code ändern, damit er viel mehr Argumente akzeptiert und die Methode in mehrere Methoden über mehrere Ebenen aufteilt.

Angenommen, die Protokollierung wird hinzugefügt, wenn ein Fehler auftritt. Was brauche ich dann, um die Logging-Komponente separat zu testen, oder mit der Originalmethode verkettet?

Das bedeutet, dass der ursprüngliche Komponententest tatsächlich zu einem Integrationstest wird, da ich jetzt mehrere Komponenten zusammen prüfe.

Ist das etwas, das vermieden werden sollte, oder wie löst man diese Art von Problemen, wenn nötig?

Mit freundlichen Grüßen

Answer 1

TDD in der realen Welt die beiden tatsächlich verwendet Unit-Tests und Integrationstests. Komponententests werden in Lernprogrammen gezeigt, weil es einfacher ist, einfache Beispiele zu verstehen, aber echte Anwendungen benötigen einige Integrationstests. Es ist typisch für den ersten Test, den Sie schreiben, ein Integrationstest zu sein (siehe bdd).

Integrationstests sind jedoch langsam und schwer zu warten (sie berühren mehr vom System als Komponententests, so dass sie häufiger wechseln). Daher ist es gut, nur so viele Integrationstests zu haben wie nötig Testen mit Unit Tests, wie es sinnvoll ist.

Wenn Anforderungen an eine Klasse dazu führen, dass sie größer wird und Sie die Klasse in kleinere Klassen umstrukturieren, sind die Komponententests jetzt Integrationstests. Berücksichtigen Sie dies, indem Sie fokussierte Komponententests für die neuen Klassen schreiben und die meisten der alten Tests für die ursprüngliche Klasse entfernen. Es kann sinnvoll sein, einen oder einige der alten Tests als Integrationstest zu verlassen. Es kann auch angebracht sein, einige der alten Tests neu zu schreiben, um Testdoppelwerte (Stubs, Mocks usw.) für das, was jetzt Instanzen anderer Klassen sind, zu verwenden. Zufälligerweise schrieb ich kürzlich an answer about the mechanics of rewriting tests when you refactor a class out of another class.

Answer 2

TDD oder nicht, die Idee eines Komponententests besteht darin, dass Sie eine Einheit der Anwendung isolieren und deren Code isoliert abfragen. Eine Einheit ist normalerweise eine Klasse und Sie würden mindestens einen Einheitentest pro Codezweig einer Methode betrachten. Z.B. Wenn classA.methodA() über 3 Zweige verfügt, werden für diese Methode 3 Unit-Tests durchgeführt.

Ein echter Komponententest injiziert die Mocked/Stubbed-Abhängigkeiten in die Komponente, ruft die zu testende Methode auf und überprüft ihr Verhalten und/oder ihren Objektstatus. Unit-Tests sollten Sie im Prinzip dazu ermutigen, das Design Ihres Quellcodes in Bezug auf lose Kopplung, Trennung von Problemen usw. zu verbessern (SOLID-Prinzipien).

Außerdem ist die Codeabdeckung ein gutes Maß für die Qualität Ihrer Komponententests, aber das Streben nach 100% wird nicht empfohlen. Außerdem ist das Schreiben von Komponententests für jede Anwendungsschicht übertrieben; Sie sollten auf Layer mit Geschäftslogik abzielen, um einen guten Return-of-Investment zu erzielen. Schreiben Sie schließlich keine Komponententests ohne Continuous Integration-Pipeline, da sie sehr schnell veralten.

Im Gegenteil, wenn Sie zwei oder mehr Geräte als einen Test verifizieren, wird dies zu einem Integrationstest, da Ihr Testergebnis vom Erfolg oder Fehlschlag jedes Geräts beeinflusst wird. Diese erfordern in der Regel mehr Aufwand für die Einrichtung der Umgebung, können aufgrund externer Abhängigkeiten flockig sein und auf Basis des Transaktionsvolumens langsam sein. Diese sind definitiv nützlich und Sie sollten eine Codeabdeckung basierend auf Ihren Budgetbeschränkungen anstreben. Integrationstests sollten ebenfalls Teil der CI/CD-Pipeline sein, könnten jedoch seltener ausgeführt werden als Komponententests.

Hoffe, das hilft.

Answer 3

Es gibt keinen grundlegenden Unterschied zwischen einem Komponententest und einem Integrationstest.

Ein niedriger (Einheits-) Test einer Ihrer Klassen wird wahrscheinlich auch Klassen verwenden, die von Ihrer Laufzeitumgebung oder Ihrem Anwendungsframework bereitgestellt werden. So könnte Ihr Komponententest auch als Integrationstest der Kombination Ihres Codes mit dem Code der Laufzeitumgebung betrachtet werden.

Ohne grundsätzlichen Unterschied gibt es keinen Grund zur Sorge, wenn etwas, das einmal als "Komponententest" bezeichnet wurde, jetzt als "Integrationstest" bezeichnet wird.

Answer 4

Zusätzlich zu den anderen Antworten können Sie sich die extended TDD cycle, wie im Buch Growing Object-Oriented Software Guided by Tests definiert, ansehen. Sie verwenden Akzeptanztests, um die innere Schleife von Schreibeinheitstests zu steuern; Je nach Situation habe ich jedoch festgestellt, dass Sie dafür auch Integrationstests verwenden können.

Also keine Notwendigkeit, sie zu vermeiden. Was nach meiner Erfahrung zählt, sind die Granularität und die Anzahl der Tests (weniger Integration, mehr Komponententests).