Wie passen Integrationstests in eine agile Umgebung mit Continuous Integration? Was bedeutet Continuous Integration für Agile Testing in einer Umgebung, wo der Code ständig neu strukturiert und mit neuen Funktionen erweitert wird?
Wie Integrationstests mit Continuous Integration in Agile Testing funktionieren
Lasst uns zuerst unsere Begriffe definieren. Traditionell wurden Integrationstests zwischen Komponententests und Validierungstests durchgeführt. Dieses Modell passt gut in eine Wasserfallumgebung, in der die Entwicklungsphasen klar und deutlich sind.
In agilen Umgebungen löst jeder Code, den ein Entwickler festlegt, einen Build-Zyklus aus. Die Abgrenzung der Phasen ist verschwommen und alles scheint gleichzeitig zu geschehen. Was bedeutet Integrationstest in diesem Zusammenhang und wo passt es in den Prozess? Im Folgenden sind sechs Methoden aufgelistet die einen reibungslosen Continuous Integration in Agile Testing beschreiben.
1. Komponententest vor Integrationstest durchführen
Für die meisten von uns ist diese Idee nicht neu. Jeder von uns kennt je später man einen Fehler im Entwicklungszyklus entdeckt, desto teurer ist es den Fehler zu beheben. Wir versuchen, alle Details zu perfektionieren, bevor wir zu dem Integrationstest übergehen. Das Problem ist, dass dieses Vorgehen dem Wasserfallentwicklungsmodell entspricht, in dem man erst zum nächsten Schritt geht, wenn die aktuelle Phase abgeschlossen ist. Sobald man jedoch zur agilen Entwicklung übergeht, ist dieser Vorgang anders. Agile Methoden bieten die Flexibilität, Änderungen in der Geschäftslogik vorzunehmen, die man im weiteren Verlauf benötigt.
2. Geschäftslogik nicht mit Integrationstests testen
Geschäftslogik sollte nicht mit Integrationstests getestet werden, dafür gibt es Unit-Tests. Verwirrende Komponententests mit Integrationstests können schwerwiegende haben. Komponententests sind in der Regel sehr schnell und werden daher für jeden Build ausgeführt, der in der mit Continuous Integration Umgebung ausgelöst wird.
Da man auf die grundsätzliche Korrektheit von Code abzielt, ist es sehr wichtig, Komponententest im Agile Testing häufig auszuführen, um Fehler in der Geschäftslogik frühzeitig zu erkennen, sodass der Entwickler, der den Fehler eingeführt hat, diesen sofort beheben kann. Integrationstests dauern dagegen viel länger, sodass sie nicht in jedem Build-Zyklus enthalten sein sollten, sondern eher in einem täglichen Build.
3. Unterschied zwischen Integrationstests und Komponententests kennen
Es gibt viele Anzeichen, die einem helfen, einen Komponententest von einem Integrationstest zu unterscheiden:
Kapselung: Während Komponententests gut gekapselt sind und keine externen Ressourcen verwenden, verwenden Integrationstests zusätzliche Komponenten oder Infrastrukturen wie das Netzwerk, die Datenbank oder das Dateisystem.
Komplexität: Unit-Tests zielen auf kleine und unterschiedliche Teile des Codes ab, sodass sie normalerweise einfach zu schreiben sind. Integrationstests sind komplexer und erfordern oft Werkzeuge und Einrichtung verschiedener Infrastrukturen.
Testfehler: Wenn ein Komponententest fehlschlägt, liegt ein Fehler in der Geschäftslogik des Codes vor. Wenn ein Integrationstest fehlschlägt, sollten Sie sich den Code, der die Geschäftslogik implementiert, nicht ansehen. Die Unit-Tests sollten Bugs auf dieser Ebene ausspülen. Es ist wahrscheinlicher, dass sich etwas in der Umgebung verändert hat und angesprochen werden muss.
4. Testsuiten in Agile Testing getrennt halten
Integrationstests in Agile Testing sollten nicht zusammen mit Komponententests ausgeführt werden. Entwickler, die an einer bestimmten Geschäftslogik im Code arbeiten, müssen in der Lage sein, Komponententests auszuführen um direkten Feedback zu erhalten, damit sie sicherstellen können, dass sie vor dem nächsten Commit von Codes keine Fehler eingebaut haben. Wenn die Testsuite zu lange dauert und der Entwickler es sich nicht leisten kann, darauf zu warten bis er den nächsten Code zu schreiben, wird er wahrscheinlich einfach aufhören zu testen. Dies bedeutet auch, dass die Komponententests nicht ordnungsgemäß gewartet werden können und der Aufwand die Testsuite mit dem Code auf den neuesten Stand zu halten zu Lieferverzögerungen führen kann.
Wenn man die Testsuiten im Agile Testing getrennt hält, können die Entwickler die schnellen Komponententests während der Entwicklung und vor der Eingabe von Code ausführen. Die langen und aufwändigen Integrationstests sollten für den Build-Server in einer separaten Testsuite reserviert sein und weniger häufig ausgeführt werden.
5. Ausführliche Protokollierung
Ein Komponententest hat einen bestimmten Gültigkeitsbereich im Agile Testing und es wird ein sehr kleiner Teil der Anwendung getestet. Wenn der Komponententest fehlschlägt, ist es normalerweise ziemlich klar was das Problem ist. Integrationstests können sehr unterschiedlich sein. Umfang der Integrationstest in Agile Testing kann mehrere Softwaremodule umfassen, ganz zu schweigen von verschiedenen Geräten und Hardwarekomponenten. Wenn ein Integrationstest fehlschlägt, kann die Ursache daher viel komplexer sein.
Eine umfassende Protokollierung ist die einzige Möglichkeit, einen Fehler zu analysieren, damit man erkennt, wo das Problem liegt. Dabei sollte man beachten, dass eine umfassende Protokollierung einen erheblichen Einfluss auf die Leistung und den Aufwand im Agile Testing haben kann. Daher sollte man nur bei Bedarf protokollieren. Um den Mehraufwand des Protokollierens geringer halten zu können sollte ein gutes Fehlermanagementsystem ausgewählt und verwendet werden.
6. Nicht nach dem Integrationstest aufhören
Das Testen endet nicht damit, wie Ihre Softwaremodule miteinander arbeiten oder wie sie mit anderen Modulen von Drittanbietern arbeiten. Es geht darüber hinaus. Ihre Software wird in einem vollständigen Produktions-Ökosystem bereitgestellt, das Virtualisierungstools, Datenbanken, Mail-Server, Load Balancer, DNS-Server, Proxy-Server und mehr umfasst. Die Benutzererfahrung Ihrer Kunden hängen nicht nur von Ihrer Anwendung ab, sondern auch davon, wie sie in Ihrer Produktionsumgebung eingesetzt wird und wie sie mit all diesen anderen Peripheriekomponenten funktioniert. Wenn Sie also Ihre High-Level-Architektur mit Integrationstests validiert haben, führen Sie auch Systemtests durch, die Ihre Produktion genau simulieren Umgebung.
Integrationstests sind teuer, aber lohnen sich
Ein wichtiger Punkt bei all dem ist, dass es teuer sein kann, Integrationstests richtig und zum richtigen Zeitpunkt im Entwicklungszyklus durchzuführen. Es wird jedoch sehr viel teurer sein, Fehler in Ihrer High-Level-Architektur zu beheben, wenn sie erst viel später entdeckt werden. Haben Sie Fragen oder benötigen Sie Hilfe bei dem Thema Continuous Integration? Gerne helfen wir Ihnen weiter. Kontaktieren Sie uns einfach.
Neueste Kommentare