Containerbasierte Integrationstests

Integrationstests bleiben ein wichtiger Bestandteil des CI / CD-Produktionszyklus, einschließlich der Entwicklung containerisierter Anwendungen. Integrationstests sind in der Regel keine sehr langen, aber sehr ressourcenintensiven Workloads. Lassen Sie uns sehen, wie Sie Integrationstesttechnologien und -tools mit Container-Orchestrierungs-Tools (insbesondere mit Red Hat OpenShift ) kombinieren können, um das Testen zu beschleunigen, die Dynamik zu erhöhen und Ressourcen effizienter zu nutzen.



Lassen Sie uns Integrations-BDD-Tests ( verhaltensgesteuerte Entwicklung ) mit Cucumber , Protractor und Selen erstellen und diese mit Zalenium auf der OpenShift-Plattform ausführen.

BDD-Test

Bei der Entwicklung von Integrationstests ermöglicht BDD Business Analysten (BAs), Definitionen von Integrationstests zu erstellen, nicht nur von Programmierern. Dank BDD kann der Entwicklungsprozess so organisiert werden, dass funktionale Anforderungen und Definitionen von Integrationstests gleichzeitig erstellt und gleichzeitig von Geschäftsanalysten erstellt werden.

Dies ist viel besser als herkömmliche Ansätze, wenn Sie zuerst die Geschäftsfunktionalität der Anwendung bestimmen und dann die QS-Abteilung Integrationstests erstellt, wie in der folgenden Abbildung dargestellt:



Und so sieht es bei der Verwendung von BDD aus:



Darüber hinaus benötigt in diesem neuen Schema jede Iteration normalerweise weniger Zeit.

Geschäftsanalysten können Definitionen für Integrationstests erstellen, da BDD diese Tests in einer einfachen und verständlichen Gurkensprache beschreibt , deren Hauptschlüsselwörter "Gegeben", "Wann" und "Dann" sind. Jede Aussage in der Gurkensprache muss mit einem dieser Wörter beginnen.

Zum Beispiel:

Wenn der Benutzer zur Anmeldeseite navigiert ist (vorausgesetzt, der Benutzer hat auf die Anmeldeseite zugegriffen)

Wenn der Benutzer Benutzername und Passwort eingibt

Wenn Benutzername und Passwort korrekt sind

Dann meldet das System sie an (dann erlaubt ihm das System, sich anzumelden)

Eine beliebte Laufzeit, die Gurkentests interpretieren kann, ist Gurke . Um Cucumber verwenden zu können, muss ein Entwickler bestimmte Funktionen implementieren, damit alle Gherkin-Anweisungen ausgeführt werden können. Gurke hat Bindungen zu vielen Programmiersprachen. Es wird empfohlen (aber nicht erforderlich), Tests in derselben Sprache wie die zu testende Anwendung zu verfassen.

Testing Technology Stack

Schauen wir uns das Testverfahren am Beispiel der TodoMVC- Webanwendung bei der Implementierung von AngularJS an . AngularJS ist ein beliebtes Framework zum Erstellen von Single-Page-Anwendungen (SPA).

Da AngularJS JavaScript ist, verwenden wir Cumcumber.js , eine Gurkenbindung an JavaScript.

Um die Arbeit des Benutzers in einem Browser zu emulieren, verwenden wir Selenium . Selen ist ein Prozess, der einen Browser starten und Aktionen von Benutzern auf Befehle wiedergeben kann, die über die API empfangen werden.

Schließlich werden wir Protractor verwenden , um die Nuancen der Emulation von in AngularJS geschriebenen SPA-Anwendungen zu berücksichtigen. Winkelmesser kümmert sich um die Erwartung, dass die Ansichten innerhalb der Seite korrekt geladen werden.

Unser Teststapel lautet also wie folgt:



Der in diesem Diagramm dargestellte Prozess wird wie folgt beschrieben:

• Wenn der Gurkentest ausgeführt wird, liest Gurke die Testdefinition aus der Gurkendatei.
• Dann wird der Testcode-Implementierungscode aufgerufen.
• Der Implementierungscode für das Testskript verwendet den Winkelmesser, um Aktionen auf einer Webseite auszuführen
• In diesem Fall stellt Protractor eine Verbindung zum Protractor-Server her und gibt über die API Befehle an Selenium aus.
• Selenium führt diese Befehle in einer Browserinstanz aus.
• Der Browser stellt bei Bedarf eine Verbindung zu den Webservern her. In unserem Beispiel wird die SPA-Anwendung verwendet, daher tritt eine solche Verbindung nicht auf, da die Anwendung bereits beim Laden vom Server der ersten Seite geladen wurde.

Die Bereitstellung eines solchen Stapels in einer nicht containerisierten Infrastruktur ist nicht einfach. Und das nicht nur wegen der Vielzahl der verwendeten Prozesse und Frameworks, sondern auch, weil es immer schwierig war, einen Browser auf einem Server ohne Monitor zu starten. Glücklicherweise kann in einer Containerwelt all dies automatisiert werden.

Integrationstestfarm

Unternehmenswebanwendungen müssen für verschiedene Kombinationen von Client-Betriebssystem und Browser getestet werden. Normalerweise ist dies auf bestimmte grundlegende Optionen beschränkt, die die Situation auf den Computern der Endbenutzer der Anwendung widerspiegeln. Aber selbst in diesem Fall sinkt die Anzahl der Testkonfigurationen für jede Anwendung selten unter ein halbes Dutzend.

Wenn Sie für jede Testkonfiguration konsistent einen Stapel bereitstellen und die entsprechenden Tests darauf ausführen, ist dies zeit- und ressourcenintensiv.

Idealerweise möchte ich Tests parallel durchführen.

Selenium-Grid kann uns dabei helfen - eine Lösung, die den Selenium Hub-Anforderungsbroker und einen oder mehrere Knoten umfasst, auf denen diese Anforderungen ausgeführt werden.



Jeder Selenium-Knoten, der normalerweise auf einem separaten Server ausgeführt wird, kann für eine bestimmte Kombination aus Client-Betriebssystem und Browser konfiguriert werden (in Selenium werden diese und andere Merkmale des Knotens als Funktionen - Eigenschaften bezeichnet). Gleichzeitig ist der Selenium Hub intelligent genug, um Anforderungen, die bestimmte Selenium-Eigenschaften erfordern, an Knoten mit diesen Eigenschaften zu senden.

Selen-Grid-Cluster sind recht schwierig zu installieren und zu verwalten, und so sehr, dass Unternehmen, die verwandte Dienstleistungen anbieten, sogar auf dem Markt erschienen sind. Insbesondere SauceLabs und BrowserStack gehören zu den Hauptakteuren.

Containerbasierte Integrationstests

Sehr oft möchte ich in der Lage sein, einen Selen-Grid-Cluster zu erstellen, der die für unsere Tests erforderlichen Selen-Eigenschaften liefert und die Tests selbst mit einem hohen Grad an Parallelisierung durchführt. Nachdem der Test abgeschlossen ist, möchte ich diesen Cluster vollständig zerstören können. Mit anderen Worten, um zu lernen, wie Anbieter von Integrationstestfarmen selbst arbeiten.

Dieser Technologiebereich befindet sich noch in einem frühen Stadium der Entstehung. Ein vielversprechendes Open-Source-Projekt - Zalenium - bietet jedoch einige unserer Anforderungen.

Zalenium verwendet einen modifizierten Hub, der bei Bedarf Knoten erstellen und diese zerstören kann, wenn sie nicht mehr benötigt werden. Zalenium unterstützt derzeit nur Chrome- und Firefox-Browser auf der Linux-Plattform. Mit dem Aufkommen von Windows-Knoten für Kubernetes wird möglicherweise Unterstützung für Explorer und Edge unter Windows angezeigt.

Wenn Sie alles zusammenfügen, lautet der technologische Stapel wie folgt:



Jedes Oval im Diagramm ist ein separater Pod in Kubernetes. Die Pods des Testspielers und der Emulatoren sind kurzlebig und werden am Ende des Tests zerstört.

Durchführen von Integrationstests innerhalb der CI / CD-Pipeline

Erstellen wir eine einfache Pipeline in Jenkins, um zu zeigen, wie diese Art von Integrationstests in den Rest des Release-Management-Prozesses integriert werden kann. Es sieht so aus:



Ihre Pipeline kann variieren, Sie haben jedoch weiterhin die Möglichkeit, die Integrationstestphase ohne nennenswerte Codeumgestaltung wiederzuverwenden.

Da die meisten Herde kurzlebig sind, besteht eine der Aufgaben der Pipeline darin, Testergebnisse zu sammeln. In Jenkins kann dies mithilfe der Archiv- und PublishHTML-Grundelemente erfolgen.

Dies ist ein Beispiel für einen Bericht über die Testergebnisse (beachten Sie, dass die Tests in zwei Browsern ausgeführt wurden):

Fazit

Trotz der Komplexität der Organisation einer End-to-End-Integrationstestinfrastruktur vereinfacht der Ansatz „Infrastruktur als Code“ den Prozess. Das Durchführen von Integrationstests auf verschiedenen Kombinationen von Betriebssystemen und Browsern erfordert viel Zeit und Ressourcen, aber Container-Orchestrierungs-Tools und kurzlebige Workloads helfen, dieses Problem zu lösen.

Auch ohne ausgereifte Tools zur Organisation von containerorientierten Integrationstests können Integrationstests auf Basis von Containerplattformen bereits heute durchgeführt werden und den Container-Ansatz nutzen.

Wenn Sie containerisierte Anwendungen entwickeln, versuchen Sie, diesen Ansatz in der CI / CD-Pipeline zu verwenden, und prüfen Sie, ob er die Integrationstests vereinfacht.

Beispielcode aus diesem Artikel finden Sie auf der GitHub-Website unter redhat-cop / container-pipelinesh.