Testautomatisierung: API-basiertes Modell

Der König ist tot, es lebe der König

Da sich die Technologie weiterentwickelt, aktualisieren Branchen ständig ihre Praktiken, um mit den neuesten Fortschritten Schritt zu halten. Alte, obwohl weit verbreitete Technologien haben eine begrenzte Lebensdauer und müssen irgendwann durch neue, besser geeignete ersetzt werden. Ein Beispiel dafür ist die Verwendung des Page Object Model (POM) in der Testautomatisierung.

Obwohl POM jahrelang ein Industriestandard war, passt es möglicherweise nicht optimal zu modernen Testanforderungen. In diesem Artikel werden wir die Schwächen von POM untersuchen und einen alternativen Ansatz vorschlagen: das API-basierte Modell.

Was ist das Page Object Model (POM)?

POM ist ein bewährtes und gängiges Industriestandard-Designmuster, das in der Testautomatisierung verwendet wird, um eine Test-Codebasis für Anwendungen zu organisieren und zu pflegen. Schaut euch diesen Artikel an, der dies als Best Practice mit einer Reihe von Codebeispielen empfiehlt. Oder schaut euch diesen Artikel mit einigen Visualisierungen an, wie POM funktioniert.

Alles in allem beinhaltet POM die Erstellung von Seitenklassen, die den Seiten der Anwendung entsprechen und alle verschiedenen Objekte auf diesen Seiten enthalten – also WebElements wie Schaltflächen, Links und Formulare. Diese Seiten und WebElements werden dann in Testskripten verwendet, um mit der zu testenden Anwendung zu interagieren.

Veranschaulichen wir, wie POM funktioniert – in einer eigenständigen Version ohne unterstützende Tools:

Abstrahierte Beispiele für Vertragsunterzeichnungs- und Drucktestfälle mit einfachen Schritten wurden verwendet, um das Bild zu zeichnen (Login- und „Neuen Vertrag erstellen”-Testfälle wurden absichtlich weggelassen – sie würden sich genauso verhalten).

Aus dem obigen Bild kann man sehen, wie POM als Proxy zur Anwendung fungiert und einen einzigen Einstiegspunkt für alle während des Testens durchgeführten Aktionen schafft. Man sollte eine dicke rote Linie erkennen können, die hervorhebt, wie stark POM auf die UI der Anwendung angewiesen ist, um testbezogene Aktivitäten durchzuführen. Haftungsausschluss: Das ist das Hauptproblem, das wir hier in Frage stellen werden. Hier ist ein Artikel aus dem Cypress-Blog, der diese Meinung teilt und eine weitere Alternative zu POM bietet.

Andererseits beschreiben und loben unzählige Online-Artikel POM – und sie haben nicht Unrecht. POM hat viele Vorteile und einige Nachteile, und seien wir ehrlich: Die Verwendung eines beliebigen Designmusters ist besser als gar keines, oder?

Schauen wir uns diese Vorteile an:

Testwartung – Wenn sich die Anwendung ändert, müssen auch alle betroffenen Tests aktualisiert werden. POM bietet einen einzigen Zugriffspunkt, da alle Tests dieselben Seitenelemente teilen. Das Beheben dieser Elemente ist weitaus einfacher als das Beheben aller betroffenen Tests.

Code-Abstraktion – POM schafft eine klare Trennung zwischen der Testmethode und der Schrittimplementierungsebene, sodass man klare Testmethoden mit Schritten wie loginPage.setUsername("John") oder loginPage.clickLoginButton() schreiben kann. Alle technischen Details gehen in die Schrittimplementierungs- (POM-)Schicht. Für konkrete Beispiele kann auf diesen Artikel verwiesen werden.

Was sind die Nachteile von POM?

Obwohl POM in der Branche lange Zeit weit verbreitet war, hat es einige Einschränkungen, die es für moderne Testanforderungen weniger geeignet machen, insbesondere im großen Maßstab. Sie zwingen dazu, zusätzliche Tools einzuführen, wie Datenbankskripte und – ja – auch die API (wir sprechen weiter unten über dieses hybride Modell).

Hier sind einige Probleme, die mit POM einhergehen:

POM ist zeitaufwändig in der Wartung – Dieses Modell fügt eurem Test-Framework eine weitere unabhängige Schicht hinzu, die Wartung erfordert. Diese Schicht dient nur einem Zweck, und das Erstellen und Pflegen von Objekten für jedes Element auf einer Webseite ist ein zeitaufwändiger Prozess. Da Webseiten immer komplexer und dynamischer werden, kann es ziemlich schwierig sein, mit Änderungen und Aktualisierungen Schritt zu halten. Das führt zu einer Codebasis, die schwer zu warten ist und den Testprozess verlangsamen kann.

POM ist zeitaufwändig in der Ausführung – Dieses Modell verlässt sich auf die UI, um Testaktionen durchzuführen, was zu sehr langen Testläufen führen kann. Besonders wenn Tests von einer (fast) sauberen Datenbank aus gestartet werden und sich nicht auf vorhandene Testdaten verlassen. Autonome Tests, die sich nicht auf vorbereitete Datenbanken stützen, sind im großen Maßstab praktisch unmöglich.

POM ist in der Ausführung fehleranfällig – Jeder Test muss jede Aktion in der UI durchführen, was normalerweise Login, Navigation, Vorbereitung usw. umfasst. Das vollständige Laden jeder Seite und die Interaktion mit so vielen Elementen wird irgendwann zufällig fehlschlagen. Das führt zu flaky Tests, zu Test-Wiederholungen, und… ihr wisst, wie das endet.

POM hat Datenbankvoraussetzungen-Overhead – Jedes größere Projekt, das POM verwendet, erfordert erhebliche Zeit, um entweder einen Datenbank-Snapshot mit notwendigen Testdaten vorzubereiten, Datenbankabfragen vorzubereiten, die die Datenbank vor jedem Testlauf befüllen, oder sogar auf Teardowns zurückzugreifen (was übrigens ein Anti-Pattern in der Testautomatisierung ist). Manche werden sich einfach darauf verlassen, ältere, bereits vorhandene Testdaten zu verwenden und gar keine Bereinigungen durchzuführen. All das führt zu vielen Problemen in der Zukunft. Andererseits werden die meisten Projekte wahrscheinlich die API nutzen, um Testdaten on-the-fly zu befüllen – und das sind erste Schritte in Richtung eines API-basierten Modells und starke Schritte in Richtung eines hybriden Modells.

Bevor wir fortfahren, nehmen wir uns einen Moment, um einen der Grundpfeiler einer ordentlichen Testautomatisierung zu würdigen: autonome Tests.

POM bleibt in diesem Bereich hinter den Erwartungen zurück und reicht allein einfach nicht aus, um echte autonome Tests zu fördern. Projekte müssen sich auf die API oder eine andere Lösung verlassen, um das zu ermöglichen. Bald enden Projekte mit einem hybriden Modus aus zwei Schichten, die beide Wartungsaufwand erfordern. Meiner Meinung nach ist das keine gute Lösung.

Die Alternative: API-basiertes Modell

Ein anderer Ansatz zur Testautomatisierung ist das API-basierte Modell. Obwohl es nichts Bahnbrechendes oder Neues auf dem Markt ist, macht es POM bei richtiger Anwendung überflüssig. Hier ist die goldene Faustregel für dieses Modell:

Jede Aktion in der UI einmal durchführen – danach stets die API verwenden

Dieser Regel folgend, würde ein Cypress-Testfall-Beispiel so aussehen:

it('Sign contract', () => { 
    cy.login(); 
    const contractData = { name: 'my contract' }; 
    cy.createNewContract(contractData).then(contractId => { 
        cy.visit('/contract/' + contractId); 
        cy.contains('Sign contract').click(); 
        cy.contains('Contract is signed').should('be.visible'); 
    }); 
});
it('Print signed contract', () => { 
    cy.login(); 
    const contractData = { name: 'my contract' }; 
    cy.createNewContract(contractData).then(contractId => { 
        cy.signContract(contractId); 
        cy.visit('/contract/' + contractId); 
        cy.contains('Print contract').click(); 
        cy.contains('Print successful').should('be.visible'); 
    }); 
});

Beachtet, dass die Vertragsunterzeichnungs-Aktion nur im ersten Testfall über die UI durchgeführt wird? Im zweiten Test wurde der benutzerdefinierte Befehl verwendet, der das über die API durchführt.

Schauen wir uns an, wie diese API-Befehle in der Datei commands.ts (der API-Schicht) aussehen würden:

Cypress.Commands.add('login', () => { 
    const userData = { username: 'myUser', password: 'myPassword' };
    cy.request({ 
        method: 'POST', 
        url: 'api/login', 
        body: userData 
    });
});
Cypress.Commands.add('createNewContract', contractData => {
    cy.request({ 
        method: 'PUT',
        url: 'api/contract/create',
        body: contractData
    }).then(response => response.body.id); // response.body.id will be returned as a result of this function
});
Cypress.Commands.add('signContract', contractId => { 
    cy.request({ 
        method: 'GET', 
        url: 'api/contract/sign/' + contractId 
    }); 
});

Das veranschaulicht, wie ein API-basiertes Modell unter der Haube funktionieren würde:

Beim Vergleich dieses Bildes mit dem vorherigen wird deutlich, wie die schwere Arbeit an die API-Schicht der Anwendung delegiert wird, während nur der Kern des Tests über die UI durchgeführt wird. Das nutzt die Stärken der Anwendung angemessener.

Analysieren wir die oben aufgeführten Vorteile von POM, diesmal im API-basierten Kontext:

Testwartung – Die Einhaltung der Goldregel bietet ein Setup, das – genau wie POM – ermöglicht, das Problem an nur einer Stelle zu beheben.

Code-Abstraktion – Die Schrittimplementierungs-(API-)Schicht kann so abstrahiert werden, wie gewünscht, und dasselbe gilt für die Testmethoden-Schicht. Alle gewünschten Abstraktionen hinzufügen, ob durch Utility-Klassen oder Funktionen.

Vergleichen wir nun die oben aufgeführten Probleme von POM und sehen, ob sie für dieses Modell gleich sind:

Das API-basierte Modell IST zeitaufwändig in der Wartung – Dieses Modell führt ebenfalls eine zusätzliche Schicht zur Wartung ein. Leider gibt es keine Möglichkeit, das zu umgehen. Es gibt jedoch einen Pluspunkt: Die API-Schicht kann für API-Tests wiederverwendet werden, und umgekehrt. Das ermöglicht Zeit- und Aufwandseinsparungen bei der Testerstellung und -wartung. Darüber hinaus ermöglicht es einen ganzheitlicheren Testansatz, bei dem UI und API mit demselben Tool getestet werden können, um bessere Qualität, Testabdeckung und einen effizienteren Gesamttestprozess zu gewährleisten.

Das API-basierte Modell ist NICHT zeitaufwändig in der Ausführung – Da dieses Modell direkt mit der API der Anwendung interagiert, erstellt es Testdaten in (Milli-)Sekunden. Es ist blitzschnell. Das ermöglicht die Erstellung notwendiger Testdaten on-the-fly und macht Tests wirklich autonom. Außerdem ist das erneute Ausführen komplexer Testfälle, die auf vielen Testdaten beruhen, so einfach wie möglich, und ihre Wartung ist recht unkompliziert.

Das API-basierte Modell ist NICHT fehleranfällig in der Ausführung – Während der Testvorbereitung verlässt sich dieses Modell nicht auf einen Browser, um eine Webseite vollständig zu rendern, es muss keine zusätzlichen Ressourcen laden (wie Bilder, JavaScript- oder CSS-Dateien), noch muss es in irgendeiner Weise mit der Seite interagieren. Die Wahrscheinlichkeit, dass etwas schiefgeht, ist drastisch geringer, was es extrem robust macht. Frontend-Probleme in der Anwendung halten nicht alle anderen Tests auf. Die Fehleranfälligkeit der Seite ist nur auf den Kern des Testfalls beschränkt.

Das API-basierte Modell hat KEINEN Datenbankvoraussetzungen-Overhead – Im Gegensatz zu POM seid ihr bei der Verwendung dieses Modells frei zu wählen, ob ihr mit einer sauberen Datenbank beginnen und alle Testdaten on-the-fly aufbauen möchtet oder eine Art vorbereitete Umgebung verwenden möchtet. Dieses Modell steht euch nicht im Weg.

Abschließend nennen wir einige Nachteile, die dieses Modell hat, die POM nicht hat:

Testdatenformat – Der größte Nachteil dieses Modells besteht darin, dass alle Testdaten für die Testvorbereitung den bestehenden API-Spezifikationen entsprechen müssen. Das kann unverständlich und schwer zu verstehen oder zu schreiben sein, hauptsächlich abhängig davon, wie gut der API-Server von Entwicklern geschrieben wurde oder wie vertraut man mit der JSON-Syntax ist.

Mobile Tests – Dieses Modell wäre nur für Webanwendungen geeignet, die eine standardisierte REST-Schnittstelle verwenden. Mobile Tests, insbesondere bei nativen Apps, sollten weiterhin auf POM zurückgreifen.

Client-lastige Anwendungen – Einige client-lastige Anwendungen, die den Großteil der Arbeit auf der Client-Seite erledigen, sind für dieses Modell nicht geeignet, da die API nicht verwendet werden kann, um die Umgebung im Voraus vorzubereiten.

Online-Ressourcen – Es gibt keine (oder zumindest konnte ich keine finden) anderen Online-Ressourcen, die die Behauptung bestätigen, dass dieses Modell tatsächlich besser für das Testen von Standard-Webanwendungen geeignet ist als POM.

Fazit

In Umgebungen, in denen Projekte schnell wachsen und Test-Frameworks exponentiell wachsen, in denen das Shift-Left-Paradigma die Testbemühungen immer früher in den Entwicklungsprozess verlagert, ist die Zeit gekommen, die alten Wege in Frage zu stellen und neuen, modernen Lösungen eine Chance zu geben.

Das API-basierte Modell bietet einen vielseitigeren, effizienteren und robusteren Ansatz, der für mehrere Testanforderungen geeignet ist. Da sich die Technologie weiterentwickelt, ist es wichtig, die Testpraktiken anzupassen, um sicherzustellen, dass sie effektiv und effizient bleiben – um das Testen und damit euer (Arbeits-)Leben einfacher zu machen.

Nutzt die nächste Gelegenheit, um dieses Modell auszuprobieren, und lasst mich wissen, wie es bei euch funktioniert hat.

Frohes Testen!