© istockphoto.com/vasabii
Teil 3: Continuous-Integration-Systeme mit Devs und Ops aufsetzen

BDD-nahe Akzeptanztests


Jenkins wurde in den vergangenen Artikeln so aufgesetzt, dass es Teile der Continuous Integration und Continuous Delivery Chain automatisiert abbilden kann. Continuous Integration bildet den Anfang der Continous Delivery Chain und kann für sich allein stehen. Sie dient dazu, dem Developerteam Qualitätssicherungsmaßnahmen automatisiert abzunehmen, um die Softwarequalität langfristig zu sichern und aufrecht zu halten.

Teilaufgaben von gängigen Continuous-Integration-Systemen sind Unit-Tests, statische Codeanalyse, Erstellung einer Quellcodedokumentation und schlussendlich die Bereitstellung und Versionierung der Build-Artefakte:

  • Continuous Integration

    • Compile Sourcecode

    • Dynamische Softwaretests (Unit-Test, TDD), inkl. Lint

    • Statische Softwaretests

    • Erstellung Dokumentation

  • Akzeptanztests (BDD)

  • Kapazitätstests

  • Exploratives Testen

  • Ausrollen

Unit-Tests bilden einen wichtigen Eckpfeiler beim automatisierten Testen von Software. Wird im Entwicklungsteam der Test-driven-Development-Ansatz verfolgt, entstehen diese Tests iterativ im Entwicklungsprozess. Testgetriebene Entwicklung zeichnet sich dadurch aus, dass nicht wie allgemein im Wasserfall- oder V-Modell üblich die Tests nach der Implementierung entwickelt werden. Bei der testgetriebenen Entwicklung werden zuerst die Tests geschrieben und danach das Requirement implementiert, bis der (Unit-)Test für dieses Requirement nicht mehr fehlschlägt.

Die Vorgehensweise bei der Entwicklung von Unit-Tests und Units kann wie folgt beschrieben werden: Iterationen, wie sie von Scrum bekannt sind, finden auch bei der testgetriebenen Entwicklung Anwendung. Unit-Tests und die zu testenden Units werden parallel in kleinen, sich wiederholenden Mikroiterationen entwickelt, die hierbei nur wenige Minuten dauern sollten. In den Iterationen wiederholen sich meist drei Schritte: Im ersten Schritt wird der Test für das gewünschte fehlerfreie Verhalten geschrieben. Dieser Test wird erst mal fehlschlagen. Im zweiten Schritt wird der Programmcode der Unit solange mit möglichst wenig Aufwand angepasst, bis der Test nicht mehr fehlschlägt. Im dritten Schritt wird der soeben implementierte Codeteil sofort einem Refactoring unterzogen, um zum Beispiel Wiederholungen zu entfernen oder gegebenenfalls Teile zu abstrahieren. Dieses Refactoring kann gefahrlos durchgeführt werden, da jederzeit mit einem Testlauf sichergestellt werden kann, dass die Unit noch korrekt arbeitet.

Diese Schritte werden solange wiederholt, bis die gewünschte Funktionalität der Unit erreicht ist. Durch diese Art der Softwareentwicklung kann eine Software evolutionär und inkrementell entworfen und ständig verbessert werden. Die Unit-Tests stellen nach jedem inkrementellen Verbesserungsschritt sicher, dass die Unit weiterhin das oder die gewünschten Requirements abbildet und korrekt bedient.

Continuous-Integration-Systeme können in Zusammenarbeit von Devs und Ops ideal aufgesetzt werden. Die ersten beiden Teile der Artikelserie zeigten auf, wie Jenkins für die Continuous-Integration-Schritte entsprechend aufgesetzt werden kann.

Continuous Integration für PHP

Im PHP-Umfeld entfällt der Punkt Compile Source­code, es wird hier lediglich ein Lint zur Überprüfung der Syntax ausgeführt. Für die dynamischen Softwaretests im PHP-Umfeld benutzen wir PHPUnit inklusive eines entsprechenden Plug-ins in Jenkins. Mithilfe dieses Plug-ins können Code Coverage und die Reports in Jenkins visualisiert werden. Statische Softwaretests werden unter anderem für Styleüberprüfungen, Komplexitätsmessungen und Kopplungsmessungen verwendet. Zur Anwendung kommen hier der PHP_CodeSniffer, PHP_Depend, PHPMD und PHP CPD. Analog zu PHPUnit helfen diese Tools nur dann, wenn die Ergebnisse Jenkins inklusive History und Trend zur Verfügung gestellt werden. Hierbei sind die vorgestellten Plug-ins nützlich. Grenzwerte, die eingehalten werden müssen, können ebenfalls über ein Plug-in konfiguriert werden. Mittels dieser Grenzwerte kann festgelegt werden, dass ein Build auch dann fehlschlägt, wenn „nur“ zu viele ungültige Formatierungen gefunden werden. Dokumentation wird oft in vielen Projekten vernachlässigt, deshalb empfiehlt es sich besonders, auch diese automatisiert in der CI Chain erstellen zu lassen. phpDox ist hier eine gute Lösung, die zugleich die Ergebnisse der statischen Softwaretests mit in die Dokumentation einfließen lassen kann.

Durch ein gemeinsames Verständnis für diesen CI-Prozess und eine gemeinsame Bearbeitung im Developer- und Operationsumfeld wächs...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang