20. Oktober 2017 // von Nathalie

Praktikum bei Thomann in Berlin – Web-Tests für thomann.io

Das umfangreiche Testing-Framework von m.thomann.de ermöglicht es, Änderungen an der Website kontinuierlich zu deployen und gleichzeitig sicherzustellen, dass die grundlegenden Funktionalitäten der Shopseite nicht beeinträchtigt werden. Das Framework basiert auf Phantom.js, wurde aber so umgeschrieben bzw. erweitert, dass es für den internen Arbeitsprozess und die Projektstruktur optimal angepasst ist.

Um einen fundierten praktischen Einblick in den Aufbau und die Funktionsweise der Webtests zu erhalten, wurde es nach einer ausführlichen Einweisung in das Thema zur meiner Aufgabe, Tests für die Seite thomann.io zu erstellen. Die Arbeit mit dieser Seite bringt mehrere Vorteile mit sich: Zum einen ist dies eine kleinere und nicht stark beworbene Webseite, die zum Thomann-Universum gehört. Das heißt, eine Arbeit hieran ist unverfänglich, auch wenn einmal etwas grundlegend schief gehen sollte. Zum anderen ist sie ein kleines Projekt mit einer übersichtlicheren Struktur als das Hauptprojekt m.thomann.de. Der ausschlaggebende Punkt ist allerdings, dass für diese Seite noch keinerlei Webtests existieren. Es war daher meine Aufgabe, die Webseite zu analysieren und zunächst ein Pagemodel dafür zu erstellen. Dieses Pagemodel repräsentiert alle notwendigen Bestandteile der Seite und ist die Grundlage für alle Tests.

class ThomannIoPage extends Page {
    constructor(browser) {
        super(browser);
    }

    headline() {
        return this.element('h1').innerText;
    }

    header() {
        return new Header(this);
    }

    content() {
        return new Content(this);
    }

    footer() {
        return new Footer(this);
    }
}

module.exports = ThomannIoPage;

Repräsentation des Seitenaufbau für den Web-Test

In diesem Fall besteht die Seite aus einer Headline, einem Header, einem Content-Bereich und einem Footer. Um den Aufbau übersichtlich zu gestalten, habe ich die Einzelelemente des jeweiligen Bereiches ausgelagert.

class Header {
    constructor(page) {
        this.page = page;
        this.element = page.element('header');
    }

    get navigation() {
        return this.element.child('.nav.navbar-nav');
    }

    get logo() {
        return this.element.child('.navbar-brand');
    }

    get searchBtn() {
        return this.navigation.child('.open-button');
    }

    get searchForm() {
        return this.navigation.child('.search-form-container.form-inline');
    }

    get termInputField() {
        return this.searchForm.child('input[name="searchTerm"]');
    }

    get searchFormSubmitBtn() {
        return this.page.element('.submit-button');
    }

    isPresent() {
        return this.element.isPresent();
    }

    clickSearchBtn(callback) {
        return this.searchBtn.clickAndWaitForElement('.search-form-container.form-inline.open', callback);
    }
}

module.exports = Header;

Beispiel: Aufbau der Header-Section

Auf dieses Model aufbauend werden danach die Tests implementiert. Hierbei wird unterschieden zwischen Page-Tests und Scenario-Tests. Page-Tests prüfen die Webseite auf inhaltliche Vollständigkeit, wie zum Beispiel eine korrekte URL, korrekten Titel und das Vorhandensein aller wesentlicher Bestandteile. Sie sind wenig zeit- und ressourcenintensiv und werden daher flächendeckend und in großen Mengen implementiert. Scenario-Tests dagegen stellen bestimmte Funktionalitäten sicher. Sie sind ressourcenintensiver in der Ausführung, da hier eine Interaktion mit der Webseite geprüft wird (z.B. Kann der Kunde ein Produkt kaufen, ohne dass Fehler auftreten?). Für thomann.io habe ich getestet, ob die Suche funktioniert und die Anfrage die erwarteten Ergebnisse, wie korrekte URL und Ergebnisse, zurückliefert.

Da während des Studiums zwar immer wieder darauf hingewiesen wurde, dass das Testen von Programmcode in der Praxis einen genauso hohen Stellenwert hat und mindestens genau so viel Zeit erfordert wie seine Entwicklung, aber die Implementierung von Tests nie eine große Rolle spielte, war es für mich eine wichtige Erfahrung in einem neuen Arbeitsbereich. Zwar waren die Testcases, die ich geschrieben habe, im einzelnen nicht komplex, aber für die Lösung der Aufgabe war ich gezwungen, mich mit allen erforderlichen Komponenten auseinanderzusetzen und sie selbst zu erstellen.

Verwandte Blogposts