Wir verwenden Cookies, um unsere Webseite für Sie zu optimieren. Mit dem Besuch unserer Webseite erklären Sie sich damit einverstanden. // Our website is using cookies to improve your experience. By continuing to browse the site, you are agreeing to our use of cookies.

Weitere Informationen finden Sie in unserer Datenschutzerklärung. // For more information, please refer to our privacy policy.

Toilet Paper #97

Toilet Paper #97: Liebling, ich habe die Frontend-Tests automatisiert!

Problem

Ihr kennt das sicher: Ihr baut ein Webfrontend mit vielen Eingabefeldern und kleinen Funktionalitäts-Details. Da ist es nicht nur beim Entwickeln mühsam, zu überprüfen, ob ein Feature richtig umgesetzt ist - auch können sich leicht Bugs einschleichen. Man überprüft ja nicht nach jedem Deployment jedes vorhandene Feature.

Lösung

Die Lösung sind, wie im Backend, automatisierte Tests. Je nach Technologie arbeiten die mitgelieferten Tests meist auf Komponenten-Ebene. In der Test-Pyramide wäre das die unterste Schicht. Für Business-Features ist die oberste Schicht eine wichtige Ergänzung: UI- bzw. End-2-End-Tests kann man gut mit einer Kombination aus Selenium und Cucumber umsetzen.

Selenium nimmt Aktionen entgegen und vermittelt sie an einen Browser. Mit dem Selenium-Driver lassen sich verschiedene Eigenschaften abfragen, z.B. ob ein Element sichtbar ist. Selenium-basierte Tests können in verschiedenen Sprachen geschrieben werden und lassen sich auch an Browserstack anbinden, wo sie mit einer Auswahl an OS-/Browser-Kombinationen ausgeführt werden können.

Cucumber lässt Test-Szenarios in "Gherkin" formulieren, einer "business-readable language", für die keine Programmierkenntnisse erforderlich sind.

E2E-Tests lassen sich im Jenkins-Build integrieren, wenn man einen Headless-Browser benutzt oder auf Jenkins ein virtuelles Display mit "Xvfb" einrichtet. Wir haben für unsere Tests "selenium-cucumber-js" benutzt, das Selenium und Cucumber bündelt. Beim Durchlaufen der E2E-Tests wird auch ein Testreport im HTML-Format, mit Tortendiagrammen und Screenshots, generiert.

Beispiel

Hier testen wir, dass man auf der jambit-Webseite, wenn man den Button der Cookie-Warnung klickt, danach das Hauptbild sieht:

Feature-Datei in Gherkin:
# Feature: Freetext
Feature: jambit landing page
  # Scenario: Freetext
  Scenario: Visiting jambit.com
    # Test steps: will be matched with
    # regex terms in Step Definition
    Given I browse to "www.jambit.com"
    When I click the cookie-OK button
    Then I should see the header image
Step-Definition-Datei in Javascript:
module.exports = function() {
  this.Given(/^I browse to "([^"]*)"$/, url => {
    return helpers.loadPage(url);
  });
  this.When(/^I click the cookie-OK button$/, () => {
    return driver.findElements(by.id("cookie-ok-button")).then(button => {
      button.click();
    });
  });
  this.Then(/^I should see the header image$/, () => {
    return driver
      .findElements(by.id("header-image"))
      .then(headerImage => headerImage.isDisplayed())
      .then(result => {
        expect(result).to.equal(true);
      });
  });
};
Frontend-Tests automatisieren