wir bloggen über software_

Bei jeder Kombination technischer Tools stellt sich die Frage, ob alle Beteiligten ihre Stärken und Vorzüge ausspielen können. Ein Tool ist nur dann effizient, wenn es nicht durch das andere Tool behindert oder eingeschränkt wird. Daher werfen wir heute einen genauen Blick auf das Zusammenspiel und die möglichen Bruchstellen zweier Tools, die sich zurzeit gerade im Akzeptanztest großer Beliebtheit erfreuen. Der Akzeptanztest prüft auf dem Weg zu einer verlässlichen Softwarelösung das gesamte System auf eine andere Art und Weise als die übrigen Teststufen: aus Sicht des Users durchleuchtet er Logik und Funktionalität, muss ein adäquates Maß an menschlicher Verständigung beachten und benötigt eine effiziente technische Umsetzungsmöglichkeit. So werden an dieser Stelle Tools miteinander kombiniert, die ganz verschiedenen Ansprüchen und Sichtweisen gerecht werden müssen. Schauen wir uns zunächst die beiden von uns genutzten Tools näher an.

Das mächtige Open-Source-BDD-Tool Cucumber, hier in der Cucumber.js-Variante genutzt, bietet uns in erster Linie eine Oberfläche, um Beispiele des Systemverhaltens in einer für alle verständlichen Sprache abzubilden. Gerade im Akzeptanztest, der Schnittstelle zwischen Business-Anforderungen und fachlicher Umsetzung, ist dabei eine gemeinsame Sprache essenziell. Denn nach dem Vier-Augen-Prinzip überprüft der Akzeptanztest mit seinen Szenarios, ob die Kundenwünsche und -anforderungen auch wirklich eingehalten werden.

Scenario: Der Benutzer wird informiert, wenn keine Ergebnisse zum Suchbegriff gefunden werden
Angenommen Dirk ist auf der Mitarbeiterseite eingeloggt
Wenn Dirk nach dem Nachnamen 'Xo' sucht
Dann bekommt er einen Hinweis, dass keine Ergebnisse gefunden wurden

Das Cucumber-Framework unterstützt uns dabei mit seinem Parser-Mechanismus, der jeden Testschritt in einen automatisierbaren Code-Step übersetzt. Daneben bietet Cucumber einen eigenen Test Runner, ein Tagging- und Filtering-System sowie informative Testreports.

Automatisieren wir sodann die zuvor abgestimmten Testszenarien, soll das möglichst reibungslos, schnell und effizient ablaufen. Aus diesem Grund haben wir uns für Microsofts relativ neuen Automatisierungstool Playwright entschieden, denn Microsoft verspricht uns genau das, wonach wir suchen: Playwright sei schnell, verlässlich und stable – ohne flaky Tests, mit automatischen Waits und Retries, auf jedem Browser und jeder Plattform nutzbar und mit einem ausgeklügelten Debugging- und Tracing-System.

Jedes Tool scheint also seine Stärken und Vorzüge zu haben. Wie gut harmonieren sie aber und wo wird es eher schwierig?

Eine wundervolle Zusammenarbeit

Benutzen wir Cucumber.js und Playwright zusammen, scheinen die Zuständigkeiten auf den ersten Blick relativ klar verteilt zu sein. Dennoch gibt es bestimmte Bereiche, in denen sich Funktionalitäten und Lösungen beider Tools überschneiden. Die prominenteste Überschneidung ist dabei der Test Runner an sich. Beide Tools bringen ihn mit, nur einer kann genutzt werden. Da das Cucumber.js-Framework nicht von einem anderem als dem Cucumber Test Runner bedient werden kann, müssen wir uns gegen den Playwright Test Runner entscheiden. Glücklicherweise hat dies keine Auswirkungen auf die folgenden Features von Playwright, die auf der offiziellen Playwright-Website detailliert beschrieben sind.

Browser: Mode & Fixtures

Das Automation Tool unterstützt verschiedene Browser und bietet uns einen headless und einen headed mode

e2e/config/launchOptions.ts
import { LaunchOptions } from "@playwright/test";
export const launchOptions: LaunchOptions = {
    headless: false,
    slowMo: 0,
};

Zudem bietet es mit seinen sogenannten „Fixtures“ (browser, context, page) die Möglichkeit, einzelne Tests dank eigener Browserkontexte isoliert voneinander laufen zu lassen. Einmal gestartet, kann der Browser so im gesamten Run benutzt werden.

Locators

Gerade beim Testen auf der GUI ist die Formulierung eindeutiger Locator für das gesuchte Element das wichtigste Handwerk, um flaky oder false positive/negative Tests zu vermeiden.
Playwright bringt hierfür eine umfangreiche Library mit, die uns verschiedene Hilfsmethoden und Suchmechanismen zur Verfügung stellt. Diese als Best Practice beworbenen Locators sind für die meisten Fälle wirklich die erste Wahl und verhalten sich zudem sehr ähnlich zu der visuellen Wahrnehmung eines menschlichen Users. So wird oft nach Text, Label oder einer Rolle eines Elements gesucht. Durch Kombinationen und Filteroptionen ist es möglich, Elemente eindeutig zu selektieren.

await page.getByRole("button")
      .getByText("Suchen")
      .click();

Waits

Das Warten auf Sichtbarkeit und Interaktion eines Elements ist ein weiterer zentraler Punkt jedes Automatisierungs-Frameworks. Playwright kommt uns hier in der Tat weit entgegen. Mit Hilfe von automatischen Retries und Waits wird zunächst die Aktionsfähigkeit an sich überprüft, also beispielsweise, ob das Element geladen, sichtbar und enabled ist. Dies bewahrt uns vor expliziten waits oder assertToBeVisible. Somit werden auch an dieser Stelle falsch positive/negative Tests bzw. das Brechen des Tests an falscher Stelle verhindert. Playwright bricht den Test automatisch mit einer Fehlermeldung ab, wenn ein solcher Check nicht bestanden wurde.

Reporting

Unabhängig vom Test Runner existieren für beide Tools Reporting-Möglichkeiten. Beide sind nutzbar, man muss sich lediglich für eine entscheiden. In unserem Fall haben wir uns für das Reporting aus dem Cucumber-Umfeld entschieden. Mit Plugins lässt sich der von Cucumber generierte JSON-Report sogar noch in informative und anschauliche HTML-Reports umwandeln, die wir im Browser anzeigen lassen können – z.B. mit Hilfe des cucumber-html-reporter, der über eine eigene Dashboard-Ansicht verfügt, oder dem Java-Jenkins-Plugin cucumber-reporter speziell für Jenkins-Builds.

Ausblick

Nach diesen vielversprechenden Grundfunktionen schauen wir uns im nächsten Schritt die Debugging-Möglichkeiten, sowie Hooks und Tagging-Optionen näher an. Und so viel sei verraten: So harmonisch wie bisher bleibt es dabei nicht.