© 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 Funktio...

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