Testautomatisierung für eine ÜbungsanwendungTest automation for a practice application

Die Anwendung ist der „Toolshop", ein kleiner Online-Shop, den es nur zum Üben gibt: Angular vorn, eine PHP-API dahinter, eine Datenbank darunter. Interessant ist nicht der Shop, sondern das Gerüst darum. Ich habe es so gebaut, wie ich ein Automatisierungsprojekt beim Kunden aufsetzen würde: Ein Befehl bringt die Umgebung hoch, die Datenbank wird jedes Mal gleich befüllt, Smoke- und Regressionstests sind getrennt, und jeder Lauf hinterlässt seine Artefakte an einer festen Stelle.

The application is the “Toolshop”, a small online shop that exists only for practice: Angular at the front, a PHP API behind it, a database underneath. The interesting part is not the shop but the harness around it. I built it the way I would set up an automation project for a client: one command brings up the environment, the database is seeded the same way every time, smoke and regression tests are separate, and every run leaves its artefacts in a fixed place.

Die Umgebung ist ein Docker-Compose-Stack aus Oberfläche, Gateway, API und Datenbank. Ein Makefile ist der einzige Einstieg: make up, make seed, make smoke, make regression, dieselben Ziele lokal wie in GitHub Actions. Das Seeding wartet, bis API und Datenbank antworten, spielt die Daten ein und prüft danach die Produktanzahl, bevor ein Test startet.

The environment is a Docker Compose stack of front end, gateway, API and database. A Makefile is the only entry point: make up, make seed, make smoke, make regression, the same targets locally as in GitHub Actions. Seeding waits until API and database respond, loads the data and then checks the product count before any test starts.

Getestet wird auf drei Ebenen. Die Oberfläche prüft Robot Framework mit der Browser-Bibliothek: 15 Smoke-Tests, die bei jedem Pull Request laufen, und 20 Regressionstests für den Hauptzweig, von Filtern und Suche über Produktdetails bis zum Warenkorb. Die API prüft pytest gegen den OpenAPI-Vertrag; was der Vertrag nicht beschreibt, wird übersprungen statt als Fehler gezählt. Die Last prüft k6 in vier Szenarien, nachts Ramp und Peak, wöchentlich Soak, mit Schwellen bei 1,5 Sekunden für das 95. und 3 Sekunden für das 99. Perzentil. Jeder Lauf schreibt Berichte und Screenshots in einen nummerierten Ordner.

Testing happens on three levels. Robot Framework with the Browser library covers the user interface: 15 smoke tests that run on every pull request and 20 regression tests for the main branch, from filters and search through product details to the cart. pytest checks the API against the OpenAPI contract; what the contract does not describe is skipped rather than counted as a failure. k6 covers load in four scenarios, ramp and peak nightly, soak weekly, with thresholds of 1.5 seconds at the 95th and 3 seconds at the 99th percentile. Every run writes reports and screenshots into a numbered folder.

Gefunden hat die Suite dabei einen Fehler in der Anwendung selbst: Das Sortieren der Produktliste über die API antwortet durchgehend mit einem Serverfehler. Der Regressionstest für die Preissortierung hält das fest, und im README steht, woran man den Unterschied zwischen einem Fehler in der Anwendung und einer wackligen Automatisierung erkennt.

Along the way the suite found a defect in the application itself: sorting the product list through the API consistently returns a server error. The regression test for sorting by price records it, and the README explains how to tell a defect in the application from flaky automation.

52 Commits zwischen Dezember 2025 und Februar 2026. Seit das Projekt fertig ist, sind die Pipelines abgeschaltet; der letzte Lauf war grün. Der Code ist öffentlich, mit Testplan, Architekturbeschreibung und Anleitung zum Nachstellen.

52 commits between December 2025 and February 2026. With the project finished, the pipelines are switched off; the last run was green. The code is public, with a test plan, an architecture description and instructions for reproducing it.