COM-Entwurfsmuster für die Automatisierung mit Selenium und Cucumber

Das Component Object Model (COM) ist ein Entwurfsmuster, das es ermöglicht, Tests in Testautomatisierungsprojekten zu strukturieren. Inspiriert vom beliebten Page Object Model (POM), geht COM über die Verarbeitung ganzer Seiten hinaus und konzentriert sich auf spezifische UI-Komponenten wie Schaltflächen, Textfelder, Dropdown-Menüs oder andere wiederverwendbare Elemente.

In diesem Tutorial werden wir erklären, wie man COM implementiert, um eine Webanwendung mit Selenium WebDriver und Cucumber zu testen und wie dieser Ansatz Ihre Tests flexibler, modularer und einfacher zu pflegen machen kann.

Was ist das Component Object Model?

Das Component Object Model (COM) ist eine Weiterentwicklung des POM-Modells. Anstatt eine gesamte Seite als Objekt zu modellieren, das mit Methoden mit allen Seitenelementen interagiert, unterteilt COM die Benutzeroberfläche in einzelne Komponenten wie:

  • Schaltflächen
  • Textfelder
  • Dropdown-Menüs
  • Suchleisten
  • Tabellen

Jede Komponente ist in einer Java-Klasse gekapselt, und ihre Interaktionen werden durch spezifische Methoden verwaltet, was es ermöglicht, jedes Element unabhängig zu warten und zu testen. Dies verbessert die Wiederverwendbarkeit, Wartung und Flexibilität in Tests.

Warum COM statt POM verwenden?

1. Erhöhte Modularität

Mit COM ist jede Komponente (wie ein Button oder ein Textfeld) eine unabhängige Entität. Wenn sich eine Komponente ändert (zum Beispiel ändert sich der Text eines Buttons), müssen Sie nur die Komponentenkasse ändern, ohne andere Komponenten oder Seiten zu beeinträchtigen. Dies ermöglicht eine hohe Modularität und verhindert die Notwendigkeit, ganze Seiten für geringfügige Anpassungen zu ändern.

2. Wiederverwendbarkeit und Flexibilität

Komponenten können auf mehreren Seiten der Anwendung wiederverwendet werden, was die Code-Duplikation verringert. Zum Beispiel kann eine ButtonComponent auf jeder Seite verwendet werden, auf der der Button erscheint, was Redundanz verringert und die Flexibilität in Tests erhöht.

3. Vereinfachte Wartung

Die Wartung ist mit COM einfacher. Wenn sich eine Komponente ändert (zum Beispiel ein Button oder ein Textfeld), müssen Sie nur die Klasse ändern, die diese Komponente darstellt. Alle Tests, die diese Komponente verwenden, werden automatisch aktualisiert, ohne dass jedes Testszenario erneut besucht werden muss.

4. Anpassen an dynamische Schnittstellen

Moderne Anwendungen sind oft dynamisch, mit Schnittstellen, die sich häufig ändern. COM ist ideal für solche Anwendungen, da es das Testen von Komponenten unabhängig von der Schnittstelle ermöglicht. Sie können Komponenten ändern oder hinzufügen, ohne die Tests für andere Teile der Anwendung zu beeinträchtigen.

5. Schnellere Testautomatisierung

COM beschleunigt die Testautomatisierung. Durch die Zentralisierung der Interaktionen mit Komponenten in wiederverwendbaren Klassen müssen Tester Aktionen nicht für jede Seite oder Komponente neu definieren. Zum Beispiel kann eine  Ein-Schritt Definition für die Aktion „einen Button klicken“ in allen Tests des Projekts verwendet werden, was die für die Automatisierung von Tests benötigte Zeit erheblich reduziert.

6. Vermeidung von Arbeitswiederholungen zwischen Testern

Mit COM müssen Tester die gleiche Arbeit nicht mehr für jeden Test wiederholen. Zentralisierte Schrittdefinitionen für gängige Aktionen, wie „einen Button klicken“ oder „Text eingeben“, können von allen Testern im Projekt verwendet werden. Dies gewährleistet Konsistenz in den Tests und vermeidet unnötige Wiederholungen, was die Effizienz und Zusammenarbeit unter den Testern verbessert.

COM-Projektarchitektur

Die Architektur eines COM-basierten Projekts gliedert sich in drei Hauptbestandteile: Komponenten, Schrittdefinitionen und den Runner.

1. Komponenten

Jedes Komponente stellt ein UI-Element dar, wie z.B. eine Schaltfläche, ein Textfeld oder ein Dropdown-Menü. Diese Klassen umfassen alle möglichen Interaktionen mit dem Element.

Hier ist ein Beispiel der Klasse ButtonComponent:

Plain Text

 

2. Schrittdefinitionen

Schrittdefinitionenverknüpfen die in den Gherkin-Dateien definierten Schritte mit den Methoden in den Komponenten. Sie sind dafür verantwortlich, mit den Komponenten zu interagieren und die im Test-Szenario angegebenen Aktionen umzusetzen.

Hier ist ein Beispiel von ButtonStepDefinition:

Plain Text

 

3. Runner

Die Runner-Klasse ist dafür zuständig, die Tests mit JUnit oder TestNG auszuführen. Sie konfiguriert Cucumber so, dass die in den .feature-Dateien definierten Test-Szenarien geladen und mit den Schrittdefinitionen ausgeführt werden.

Hier ist ein Beispiel von TestRunner:

Plain Text

 

Schreiben und Erklären eines Gherkin-Szenarios

Eines der wesentlichen Elemente der Automatisierung mit Cucumber besteht darin, die Gherkin-Sprache zu verwenden, um Test-Szenarien zu schreiben. Gherkin ermöglicht es Ihnen, Tests auf eine lesbare und verständliche Weise zu beschreiben, selbst für nicht-technische Personen.

Betrachten wir ein Szenario, in dem wir die Interaktion mit einer Schaltfläche mithilfe der zuvor definierten ButtonComponent testen möchten. So könnte es in Gherkin geschrieben sein:

Scenario: User clicks on the "Submit" button
   Given I am on the login page
   When I click on the button "Submit"
   Then I should be redirected to the homepage


Erklärung des Szenarios

Szenario

Dieses Szenario beschreibt die Aktion, bei der ein Benutzer auf die Schaltfläche ‚Absenden‘ auf der Anmeldeseite klickt und sicherstellt, dass er nach dem Klicken zur Startseite weitergeleitet wird.

  • Angenommen, ich befinde mich auf der Anmeldeseite: Der Ausgangszustand des Tests ist, dass der Benutzer sich auf der Anmeldeseite befindet.
  • Wenn ich auf die Schaltfläche „Absenden: Die im Test durchgeführte Aktion besteht darin, auf die Schaltfläche ‚Absenden‘ zu klicken.
  • Dann sollte ich zur Startseite weitergeleitet werden: Die erwartete Überprüfung ist, dass der Benutzer nach dem Klicken auf die Schaltfläche zur Startseite weitergeleitet wird.

Verbindung mit COM

Jeder Schritt in diesem Szenario ist einer Schrittdarstellung in ButtonStepDefinition zugeordnet, bei der die Klickaktion von der ButtonComponent verarbeitet wird, was den Test modular und einfach zu warten macht.

Zusätzliche Erklärung

Beachten Sie, dass die Schritte den angezeigten Text auf den Schaltflächen (oder Platzhaltern in Eingabefeldern usw.) als Parameter verwenden. Dies macht die Szenarien lesbarer und generischer. Zum Beispiel wird im obigen Szenario der Text der Schaltfläche „Absenden“ direkt im Schritt „Wenn ich auf die Schaltfläche ‚Absenden.‘“ klicke, verwendet. Auf diese Weise könnte die gleiche Schrittdifferenzierung wiederverwendet werden, um eine andere Schaltfläche, wie „Anmelden,“ zu testen, indem einfach der Text im Gherkin-Szenario geändert wird. Dies verbessert die Wiederverwendbarkeit des Testcodes und macht die Szenarien intuitiver und flexibler.

Wiederverwendbarkeit von Schritten mit COM

Einer der Hauptvorteile von COM ist die Wiederverwendbarkeit von Schrittdifferenzierungen für verschiedene Schaltflächen. Zum Beispiel kann der gleiche Schritt Wenn ich auf die Schaltfläche {string} klicke für alle Schaltflächen verwendet werden, unabhängig vom angezeigten Text auf der Schaltfläche. Der COM-Ansatz ermöglicht es Ihnen, die Klickaktion dynamisch basierend auf dem Schaltflächentext zu parametrieren.

Betrachten wir ein weiteres Szenario mit einer anderen Schaltfläche:

Szenario

Plain Text

 

In beiden Fällen wird die gleiche clickButton-Methode im ButtonComponent verwendet, aber der Schaltflächentext ändert sich je nach Szenario. Dies zeigt, wie COM es ermöglicht, dieselbe Komponente und Schrittdifferenzierung wiederzuverwenden, wodurch Tests flexibel und modular werden.

Wie COM die Testautomatisierung verbessert

COM verbessert die Testautomatisierung auf mehrere Arten:

  • Reduzierung der Code-Duplikation: Durch die Verwendung wiederverwendbarer Komponenten reduzieren Sie die Code-Duplikation in Tests. Zum Beispiel beseitigt eine ButtonComponent, die auf mehreren Seiten der Anwendung verwendet wird, die Notwendigkeit, sich wiederholende Tests zu schreiben.
  • Lesbarere und modifizierbare Tests: Tests sind klarer und leichter zu verstehen, da sie von seiten-spezifischen Implementierungsdetails entkoppelt sind. Sie können sich auf die Interaktion mit Komponenten konzentrieren, ohne sich um die zugrunde liegende Seitenstruktur kümmern zu müssen.
  • Wartungsfreundlichkeit: Jede Änderung an einer Komponente (z. B. eine Änderung des Textes eines Buttons) betrifft nur die Komponentenklasse, nicht die Tests. Dies macht die Wartung viel einfacher und schneller.
  • Flexiblere Tests: Tests können leicht an sich ändernde UIs angepasst werden, da die Komponenten unabhängig voneinander sind. Sie können neue Komponenten testen oder bestehende ersetzen, ohne andere Tests zu beeinträchtigen.

Wann wird das COM-Entwurfsmuster empfohlen?

Dieses Entwurfsmuster wird empfohlen, wenn die getestete Webanwendung ein einheitliches Designsystem für alle Komponenten verwendet. Zum Beispiel, wenn alle Buttons auf die gleiche Weise deklariert sind, mit einer konsistenten Struktur für alle UI-Elemente. In solchen Fällen ermöglicht die Verwendung von COM, die Interaktionen mit jedem Komponententyp (wie Buttons, Textfeldern usw.) zu zentralisieren, was Tests modularer, wiederverwendbarer und leichter wartbar macht.

Wiederverwendung von Schrittabbildungen über mehrere Produkte hinweg

Wenn Sie mehrere Produkte entwickeln und testen, die das gleiche Designsystem verwenden, können Sie eine Bibliothek erstellen, die alle Schrittabbildungen und Aktionen (oder fast alle) für jedes Komponenten umfasst. Dies ermöglicht es Testern, sich ausschließlich auf das Schreiben von Gherkin-Szenarien zu konzentrieren, und die Tests werden automatisiert. Da alle Web-Elemente auf die gleiche Weise geschrieben sind (HTML), verhalten sich Komponenten wie Schaltflächen, Textfelder und andere UI-Elemente konsistent über alle Projekte hinweg.

Als Ergebnis müssen Tester nicht mehr die gleichen Aufgaben wiederholen – das Definieren von Schrittabbildungen und Aktionen für identische Komponenten über mehrere Projekte hinweg. Dieser Ansatz spart Zeit und verbessert die Wartbarkeit. Wenn ein Web-Element geändert wird (zum Beispiel, wenn sich der XPath ändert), müssen Sie nur dieses Element in der gemeinsam genutzten Bibliothek aktualisieren, und die Änderung wird automatisch auf alle Automatisierungsprojekte angewendet. Dies reduziert das Risiko von Fehlern und macht Updates effizienter über verschiedene Produkte hinweg.

Fazit

Das Component Object Model (COM) ist ein leistungsstarkes Designmuster zur Organisation der Testautomatisierung. Durch den Fokus auf wiederverwendbare Komponenten ermöglicht COM die Erstellung von modulareren, wartungsfähigeren und skalierbareren Tests. Dieses Muster ist besonders nützlich für moderne Anwendungen, in denen sich die Benutzeroberfläche schnell ändert und die Interaktion mit unabhängigen Komponenten wesentlich ist.

Mit wiederverwendbaren Tests, vereinfachter Wartung und einer flexiblen Architektur ist COM die ideale Lösung für die Testautomatisierung in Selenium und Cucumber Projekten.

Source:
https://dzone.com/articles/com-design-pattern-selenium-and-cucumber