Was sind Test-Treiber?

Oft auch einfach als Treiber bezeichnet, sind Komponenten im Softwaretesting, die dazu dienen, Module oder Funktionen zu testen, die noch nicht vollständig integriert sind. Sie simulieren die Funktionen einer übergeordneten Einheit und ermöglichen damit das Testen einer Software in einer isolierten Umgebung.

Warum sind Test-Treiber wichtig?

Sie erleichtern die Isolation von Softwarekomponenten und tragen zur Erstellung robuster und sicherer Anwendungen bei. Sie unterstützen den Bottom-Up-Integrationstest, bei dem einzelne Module zuerst getestet und dann schrittweise zu größeren Einheiten zusammengefügt werden. Zudem erlauben sie das frühe Aufdecken von Fehlern und Unstimmigkeiten, was zur Verbesserung der allgemeinen Softwarequalität führt.

Verschiedene Arten von Test-Treibern

Es gibt verschiedene Arten von Test-Treibern, die man jeweils für unterschiedliche Testszenarien verwenden kann. Dazu gehören unter anderem:

• Stubs: Diese simulieren die Funktionen einer Softwarekomponente, die noch nicht implementiert ist.
• Mocks: Sie ahmen das Verhalten einer bestimmten Klasse oder Methode nach und ermöglichen so das Testen unter kontrollierten Bedingungen.
• Fakes: Sie stellen vereinfachte Versionen von komplexen Objekten dar und sind hilfreich, wenn das echte Objekt schwer zu erzeugen oder zu kontrollieren ist.

Test-Treiber in der Praxis

In der Praxis kommt die Verwendung von Test-Treibern häufig im Kontext der testgetriebenen Entwicklung (TDD) „Test Driven Development“ vor. Bei dieser Methode wird zunächst ein Test geschrieben, der fehlschlägt. Anschließend entwickelt man die entsprechende Funktion so weiter, dass der Test erfolgreich durchläuft. Test-Treiber tragen dazu bei, den Entwicklungsprozess effizient zu gestalten und die Qualität der Software kontinuierlich zu überwachen.

Fazit

Zusammenfassend lässt sich sagen, dass Test-Treiber ein unverzichtbares Instrument im Softwaretest sind. Sie ermöglichen eine effektive Modulprüfung, tragen zur Fehlererkennung bei und unterstützen die Erstellung hochwertiger Softwareprodukte. Durch ihr Verständnis und ihre Anwendung können Softwareentwickler ihren Entwicklungsprozess verbessern und sicherstellen, dass das Endprodukt den Qualitätsanforderungen entspricht.

Der Beitrag Test-Treiber – Schlüssel zu effizienter Softwareentwicklung erschien zuerst auf CEOsBay.

Was ist Clean Code?

Clean Code bezieht sich auf den Ansatz, Code so zu schreiben, dass er leicht verständlich, wartbar und erweiterbar ist. Das Konzept wurde von Robert C. Martin, auch bekannt als „Uncle Bob“, in seinem Buch „Clean Code: A Handbook of Agile Software Craftsmanship“ populär gemacht. Im Kern geht es darum, Softwareentwicklung als Handwerk zu betrachten und stets auf hohe Qualität und Präzision in der Codegestaltung zu achten.

Warum ist es wichtig?

Sauberer Code bietet verschiedene Vorteile, sowohl für den Entwickler selbst, für das gesamte Team und meiner Meinung nach auch für die ganze Welt.

• Verständlichkeit: Clean Code ist einfacher zu lesen und zu verstehen. Das hilft Entwicklern, sich schneller mit dem Code vertraut zu machen und Fehler oder Verbesserungsmöglichkeiten schneller zu erkennen.
• Wartbarkeit: Sauberer Code ist leichter zu warten, da er klar strukturiert und weniger anfällig für Fehler oder unerwartete Probleme ist.
• Effizienz: Da Clean Code einfacher zu verstehen ist, kann das Team schneller arbeiten und die Produktivität steigt.
• Zusammenarbeit: Ein sauberer Code erleichtert die Zusammenarbeit im Team, da jeder den Code anderer Entwickler leichter lesen und verstehen kann.

Prinzipien von Clean Code

Es gibt viele Prinzipien und Praktiken, die beim Schreiben von sauberem Code helfen können. Einige der wichtigsten sind:

• Lesbarkeit: Der Code sollte leicht lesbar und verständlich sein. Das bedeutet, dass man Variablen, Funktionen und Klassen sinnvoll benamt und ihre Funktion leicht erkennbar ist. Kommentare setzt man sparsam ein, um den Code nicht zu überfrachten.

• Einfachheit: Man hält den Code so einfach wie möglich, ohne unnötige Komplexität oder Verwirrung. Das bedeutet, dass man sich auf das Wesentliche konzentrieren und abstrakte Konzepte wie Design Patterns oder Funktionen nur verwendet, wenn sie tatsächlich nützlich sind.

• Modularität: Man teilt den Code in kleine unabhängige Module auf, die jeweils eine bestimmte Funktion erfüllen. Dadurch wird der Code leichter zu verstehen und zu warten.

• Wiederverwendbarkeit: Man schreibt den Code so, dass die Wiederverwendbarkeit gewährleistet ist. Dies bedeutet, dass Funktionen oder Klassen, die eine bestimmte Aufgabe erfüllen, generisch genug sind, um in verschiedenen Situationen Verwendung zu finden.

Clean Code in der Praxis

Hier sind einige konkrete Schritte, die man beim Schreiben von Clean Code in der Praxis beachten sollte:

• Variablen-, Funktions- und Klassennamen: Man wählt sinnvolle, beschreibende Namen, die klar machen, was eine Variable, Funktion oder Klasse macht. Die Vermeidung von Abkürzungen oder unverständliche Namen ist eines der obersten Gebote.

• Single Responsibility Principle (SRP): Jede Funktion oder Klasse sollte nur eine einzige Verantwortung haben. Dies bedeutet, dass sie nur einen Aspekt des Problems lösen sollte, um den Code einfacher und leichter zu warten.

• Funktionen und Methoden: Man hält Funktionen und Methoden kurz und konzentrieren sich darauf, dass sie eine einzige Aufgabe erfüllen. Eine Funktion oder Methode sollte in der Regel nicht länger als 20 Zeilen sein, um ihre Verständlichkeit zu gewährleisten.

• KISS (Keep It Simple, Stupid) Prinzip: Man versucht, den Code so einfach wie möglich zu halten und unnötige Komplexität zu vermeiden. Wenn es eine einfachere Lösung gibt, zieht man diese der komplexeren vor.

• Don’t Repeat Yourself (DRY) Prinzip: Man vermeidet doppelten Code, indem man wiederverwendbare Funktionen oder Klassen erstellt. Das verringert die Wahrscheinlichkeit von Fehlern und macht den Code leichter zu warten.

• Code-Kommentare: Man sollte Kommentare dazu verwenden, den Zweck und die Funktionsweise von Code-Teilen zu erläutern, die nicht sofort offensichtlich sind. Man sollte jedoch nicht zu viele Kommentare schreiben, da dies den Code unübersichtlich machen kann.

• Fehlerbehandlung: Die Implementierung einer angemessenen Fehlerbehandlung sollte unabdingbar sein, um unerwartete Probleme zu erkennen und angemessen darauf zu reagieren. Die Verwendung von Exceptions und try-catch-Blöcken, kann eine gute Lösung darstellen, um Fehler abzufangen und entsprechend darauf zu reagieren.

• Testgetriebene Entwicklung (TDD): Man schreibt zuerst Tests, bevor man den eigentlichen Code entwickelt. Auf diese Weise kann man sicherstellen, dass die Implementierung den gewünschten Anforderungen entspricht und weniger fehleranfällig ist. Siehe hierzu meinen Beitrag über Test Driven Development.

• Kontinuierliche Integration (CI) und Continuous Deployment (CD): Man verwendet CI/CD-Tools, um den Code regelmäßig zu testen und automatisch zu deployen. Dies stellt sicher, dass der Code immer auf dem neuesten Stand ist und das man potenzielle Probleme schnell erkennen kann.

Fazit

Im Grunde genommen ist dies für mich eine relativ neue Angelegenheit, da ich in der Vergangenheit schon recht of den Code einfach reingehackt habe, da ich mich unter Zeitdruck gefühlt habe. Ich ertappe mich hin und wieder immer noch dabei und dies sehr oft, wie ich auf alte Gewohnheiten und Muster zurückgreife. Doch dies sollte sich hoffentlich in den nächsten Monaten und Jahren auf ein Minimum reduzieren lassen. Ich bin davon überzeugt, dass Clean Code ein wesentlicher Bestandteil einer erfolgreichen Softwareentwicklung ist. Indem man sich auf Lesbarkeit, Einfachheit, Modularität und Wiederverwendbarkeit konzentriert, kann man den eigenen Code nicht nur leichter verstehen, sondern auch schneller und effizienter arbeiten. Durch die Anwendung der oben genannten Prinzipien und Praktiken kann man den Code verbessern und letztendlich zu erfolgreichen, wartungsfreundlichen Softwareprodukten beitragen.

Der Beitrag Clean Code – Elegante Lösungen für effiziente und wartungsfreundliche Software erschien zuerst auf CEOsBay.

Man verwendet den Ausdruck Modultest unter anderem bei frühen Teststufen, in denen man die inneren, detailliertesten Komponenten der Software testet. Gemäß Software Validation & Verification Plan sind diese Tests nur für Module mit geringer Kritikalität nicht notwendig. Im Grunde genommen bei Fehlern, die dem User nur geringfügige Unannehmlichkeiten bereiten.

In einer Abstraktion der verwendeten Programmiersprache, spricht man von Komponente oder Softwarebaustein. Den Test eines solchen einzelnen Softwarebausteins bezeichnet man auch allgemeiner als Komponententest.

Als Testbasis kann man in der Regel die komponentenspezifische Anforderung und das Softwaredesign der Komponente (auch Komponentenspezifikation genannt) heranziehen. Für Whitebox-Testfälle oder um Aussagen zur Codeüberdeckung zu erhalten, kann man zusätzlich den Sourcecode einer Komponente analysieren und diesen als Testbasis verwenden. Wobei dabei auch Tools wie Jacoco helfen können. Ob die Komponente auf einen Testfall richtig reagiert, muss man allerdings auch hier auf Basis der Design- und Anforderungsdokumente beurteilen.

Typische Testobjekte sind wie bereits beschrieben Programmunits, -Module bzw. Klassen. Aber auch Kommandozeilenskripte des Betriebssystems (Shell-Skripte), Datenbankskripte, Datenkonvertierungs- oder Migrationsprozeduren, Datenbankinhalte sowie Konfigurationsdaten können Testobjekte sein. Kennzeichnend ist in der Regel der isolierte Test eines einzelnen Softwarebausteins. Dies dient primär, um komponentenexterne Einflüsse beim Testen auszuschließen. Alle so ermittelten Fehler kann man so dem spezifischen Modul zuordnen.

Klar zu unterscheiden ist auf jeden Fall der Integrationstest, den ich in einem separaten Beitrag thematisiere. Bei einem Integrationstest konzentriert man sich auf die Wechselwirkung mit Nachbarkomponenten.

Die Erstellung solcher Tests ist in der Regel die Aufgabe eines Programmierers. Dies liegt zum einen daran, dass man ein ausgeprägtes Verständnis für die Programmiersprache in der die Anwendung geschrieben ist haben muss. Und zum anderen daran, dass man meist auch einen Testtreiber benötigt, dessen Programmierung in der Regel auch der Entwickler übernimmt.

Einordnung im Testprozess

Algorithmen auf Unitebene besitzen meist nur eine begrenzte Komplexität und man kann sie über klar definierte Schnittstellen aktivieren. Daher kann sie mit relativ wenigen Testfällen weitgehend vollständig testen. Dies gilt als Voraussetzung für die anschließende Teststufe. Dem Integrationstest, um dort die Testfälle auf das integrierte Zusammenwirken größerer Funktionsteile oder der gesamten Anwendung ausrichten zu können. Die modulspezifischen Detailkonstellationen lassen sich damit auf Stichproben beschränken, was die Anzahl der erforderlichen Testfälle signifikant reduziert.

Zum Vergleich: Ein Gerät wird erst dann als Ganzes getestet, wenn die Funktionsfähigkeit seiner Einzelteile gesichert ist.

Test des Vertrages und nicht der Algorithmen

Man testet bei Modultests gemäß dem Design-by-contract-Prinzip möglichst nicht die Interna einer Methode, sondern nur ihre externen Auswirkungen (Rückgabewerte, Ausgaben, Zustandsänderungen, Zusicherungen). Sind die internen Details der Methode geprüft (dies wird als White-Box-Testing bezeichnet), kann der Test fehlschlagen, obwohl sich die externen Auswirkungen nicht geändert haben. Daher empfiehlt man in der Regel das sogenannte Black-Box-Testing, bei dem man sich auf das Prüfen der externen Auswirkungen beschränkt.

Was sind die Vorteile von Unit Tests?

• Mittels automatisierter Unittests kann man im Schnitt 30 % der Fehler erkennen. Bei der Verwendung von TDD (Test Driven Development) kann man im Schnitt 45 % und im besten Fall 85 % der Fehler vermeiden.
• Fehler erkennt man durch Modultests bereits während der Entwicklung. Die durch Unittests vermiedenen Fehlerkosten sind daher gemäß der Rule of Ten (Dazu später mehr) um ein Vielfaches höher als bei späteren Teststufen, was Unittests zur effizientesten Teststufe machen.
• Im Falle eines Fehlers kann man diesen sehr viel genauer eingrenzen und damit schneller finden und beheben.
• Die Tests erfüllen den Zweck einer lebenden Dokumentation. In Kombination mit einer sinnvollen Benamung der Objekte (Clean Code) können zusätzliche Dokumentationsmaßnahmen entfallen.
• Da einzelne Module nur wenige mögliche Codeausführungspfade besitzen, muss man viel weniger mögliche kombinatorische Ausführungspfade berücksichtigen als bei anderen Testarten. Bei übergeordneten Tests kann man sich dann stichprobenartig auf die wichtigsten Ausführungspfade konzentrieren und damit die Anzahl dieser Tests deutlich reduzieren.
• Da man nur einzelne Module testet, kann man Modultests, oft um mehrere Größenordnungen, schneller und damit öfter (bzw. kontinuierlich) ausführen als andere Testarten.
• Wenn man Fehler mit einem Test absichert, kann man den erneuten Auftritt des gleichen Fehlers verhindern.
• Durch die Fehlerreduktion ergeben sich Geschwindigkeitsvorteile in der Entwicklung in mittleren bis großen Softwareprojekten.
• Da man Abhängigkeiten zwingend vermeiden muss, um einen Modultest zu ermöglichen, bleibt der Code verhältnismäßig schnell änderbar. Hierdurch kann man schneller auf wechselnde Anforderungen reagieren. Siehe Agile Manifest 😉
• Da automatisch ausgeführte Tests um mehrere Größenordnungen schneller sind als manuelle Tests, reduziert sich der Zeitaufwand für das Testen deutlich. Hierdurch kann man die Entwicklungsstufen schneller durchlaufen und die Release-Zyklen signifikant verkürzen.

Was sind die Nachteile von Unit Tests?

• Bei der Implementierung neuer Funktionen muss man nicht nur die Funktion implementieren, sondern auch die dazugehörenden Tests vorbereiten bzw. definieren. Dadurch ergibt sich ein oft mehrfacher Implementierungsaufwand.
• Bei Änderungen muss man nicht nur die geänderten Funktionen, sondern auch die dazugehörenden Tests anpassen. Insbesondere bei der Entwicklung von Prototypen, bei der sich die Codebasis schnell verändert, ist das Testen daher oft eher ein Hindernis.
• Da man die Funktionalität der Tests verwendet, ist in den IDEs schwerer ersichtlich, ob eine Funktionalität keine Verwendung mehr findet und ob man es daher entfernen kann.
• Weisen die Tests untereinander Abhängigkeiten auf (z. B. durch gemeinsame Testdaten), so können einzelne Änderungen an der Codebasis eine Vielzahl von Tests beeinflussen, was den Änderungsaufwand mit der Größe der Codebasis exponentiell erhöht.

Fehlerkosten 10er Regel (Rule of ten)

Die Zehnerregel der Fehlerkosten besagt, dass je weiter ein Fehler sich unentdeckt in die späten Phasen des Werdegangs eines Produktes oder Prozesses bewegt – oder gar bis zum Kunden –, desto höher steigen die Kosten zur Behebung des Fehlers. Eindrucksvoll untermauert durch die Ergebnisse einiger Studien aus den 70er Jahren in Japan, USA und Großbritannien, die sich mit den Ursachen von Produkt- bzw. Qualitätsmängeln beschäftigten. Alle Analysen lieferten nahezu die gleichen Ergebnisse: Ca. 70 % aller Produktmängel hatten ihre Ursache bereits in der Entwicklung, Konstruktion und Arbeitsvorbereitung. Der Herstellungsprozess selbst hat bezüglich der Endqualität des Produktes offensichtlich eher einen sekundären Einfluss. Eine VDMA-Studie zum Thema „Qualitätsbezogene Kosten“ Anfang der 90er Jahre in der Bundesrepublik Deutschland bestätigt dieses Ergebnis.

Die Zehnerregel der Fehlerkosten oder „Rule of ten“ sagt aus, dass sich die Fehlerkosten für einen nicht entdeckten Fehler von Stufe zu Stufe der Wertschöpfung um den Faktor 10 erhöhen. Je früher ein Fehler entdeckt und beseitigt wird, desto kostengünstiger ist dies für die Organisation und schlussendlich auch für den User bzw. Kunden.

Ansonsten sind diese auch in der DIN 55350-11 im Rahmen des Qualitätsmanagements festgehalten. Doch darauf gehe ich in einem separaten Beitrag ein.

Wo sind die Grenzen der Unit Tests?

Unit Tests können (wie jeder Test) die Fehlerfreiheit der getesteten Units, Module usw. nicht garantieren oder nachweisen, sondern lediglich unterstützen. Die Grenzen von Unit Tests liegen primär nur in den Fällen vor in denen man Fehler finden kann, zu deren Entdeckung die verwendeten Tests geeignet sind. Eine Softwarekomponente, die „grün“ testet, ist also nur bedingt fehlerfrei.

Das Merkmal von Code, „grün“ zu testen, und durchaus auch der Wunsch nach diesem Ergebnis, kann dazu führen, dass man tatsächlich (unbewusst) nur so viel testet, bis alle Tests „grün“ sind. Module, die keine fehlschlagenden Modultests haben, als fehlerfrei zu behandeln, ist ein Fehlschluss in der Praxis des (TDD) Test Driven Development.

Um eine ausreichende Testabdeckung zu erzielen, lohnt es sich u.U., vor dem Erstellen der Testfälle Refactoring-Maßnahmen anzuwenden. Dies erst nach abgeschlossenen Unit Tests (für den alten Code) zu tun, schafft Raum (wie jede Änderung im Code) für neue Fehlerrisiken und kann deshalb wiederholtes Testen erforderlich machen.

Wenn der Autor von Unit Tests mit dem Autor der Module identisch ist, können Denkfehler in der Implementierung auch im Test erscheinen und verpasst gegebenenfalls die Chance, diese aufzudecken. Wenn es sich um dieselbe Person handelt, kann man die vorrangige Entwicklung der Tests ebenfalls nicht garantieren, da sowohl die beabsichtigte Funktionsweise des Codes als auch die zukünftige Gestalt bereits im Gedankengut des Testautors und späteren Codeautors präsent sein können. Dies kann im Extreme Programming durch „Test Ping-Pong“ abgefangen werden, bei der sich Entwickler bei der Implementierung der Funktionalität und der Tests abwechseln.

Bei der Entwicklung von Modultests können Testfälle entstehen, die der Zielsetzung und dem Charakter von Modultests nicht oder nur zum Teil entsprechen. Wie bei der Programmierung existieren daher auch für die Entwicklung von Modultests Anti-Pattern, die man möglichst vermeiden sollte.

Der Beitrag Unit Tests – Fundament für stabile und effiziente Software erschien zuerst auf CEOsBay.

Im Grunde genommen handelt es sich dabei um zwei Arten von Tools, die zum einen Anweisungen dem Java-Quellcode hinzufügen und dessen Neukompilierung einfordern und zum anderen Tools, die den Bytecode entweder vor oder während der Ausführung instrumentieren. Das Ziel von JaCoCo ist es, herauszufinden, welche Teile des Codes getestet werden, indem es die Codezeilen registriert, die man bei der Ausführung eines Tests ausführt. TDD bzw. Test Driven Development ist diesbezüglich ebenfalls ein gutes Stichwort.

Features von JaCoCo

• Abdeckungsanalyse von Anweisungen (C0), Verzweigungen (C1), Zeilen, Methoden, Typen und zyklomatischer Komplexität (McCabe-Metrik).
• Basiert auf Java-Bytecode und funktioniert daher auch ohne Quelldateien.
• Einfache Integration durch Java-Agent-basierte On-the-fly-Instrumentierung. Andere Integrationsszenarien wie benutzerdefinierte class loader sind über die API möglich.
• Framework-unabhängig: Reibungslose Integration in Java VM-basierte Anwendungen wie einfache Java-Programme, OSGi-Frameworks, Web-Container oder EJB-Server.
• Kompatibel mit allen freigegebenen Java-Klassendateiversionen.
• Unterstützung für verschiedene JVM-Sprachen.
• Verschiedene Berichtsformate (HTML, XML, CSV).
• Remote-Protokoll und JMX-Steuerung zur Anforderung von Ausführungsdaten-Dumps vom Coverage Agent zu jedem beliebigen Zeitpunkt.
• Ant-Tasks zum Sammeln und Verwalten von Ausführungsdaten und zum Erstellen strukturierter Abdeckungsberichte.
• Maven-Plug-in zum Sammeln von Abdeckungsinformationen und Erstellen von Berichten in Maven-Builds.

JaCoCo bietet die Instructions, Line- und Branchabdeckung. Im Gegensatz zu beispielsweise Atlassian Clover und OpenClover, die eine Instrumentierung des Quellcodes erfordern, kann JaCoCo Java Bytecode mit zwei verschiedenen Ansätzen instrumentieren:

1. JCov on the fly, während der Code mit einem Java-Agenten ausgeführt wird beispielsweise wie Cobertura und JCov vor der Ausführung (offline)
2. Man kann es aber auch so konfigurieren, dass man die gesammelten Daten in einer Datei speichert oder via TCP versendet. Im Gegensatz zu Cobertura und EMMA ist die Unterstützung von so ziemlich allen Java Versionen ab der Java Version 7 gewährleistet.

Tools, die JaCoCo verwenden oder enthalten

Einige davon habe ich bereits in diversen Beiträgen thematisiert. Mit einem Klick auf das jeweilige Tool kommt man auf den jeweiligen Beitrag.

• SonarQube JaCoCo Plugin – Standardmäßig für Code Abdeckungsanalysen innerhalb der Code-Qualitätsmanagement-Plattform
• EclEmma Eclipse (Software) Code Coverage Plugin
• Jenkins JaCoCo Plugin
• Netbeans JaCoCo support
• IntelliJ IDEA (Seit Version 11)
• Gradle JaCoCo Plugin
• Visual Studio Team Services
• TeamCity

Fazit

JaCoCo bietet sich für die Codeabdeckungsanalyse bei der modularen Softwareentwicklung bzw. bei den Unit Tests an. Die Abdeckungsgrade geben an, wie viele Anweisungen, Zweige usw. die Tests durchlaufen. Auf Basis der so gewonnenen Erkenntnisse kann man weitere sinnvolle Testfälle ermitteln oder aber nicht beanspruchten bzw. toten Code entfernen. Es gibt kein allgemeingültiges Mindestmaß an Codeabdeckung. Man definiert die jeweils erforderliche Testabdeckung in Anbetracht des Anwendungsfalls nach einer Risikoeinschätzung sowie der eigenen Entwickler-Fähigkeiten.

Der Beitrag JaCoCo – Messen und Optimieren von Testabdeckung für robuste Java-Anwendungen erschien zuerst auf CEOsBay.

Übrigens ist BDD aus der testgetriebenen Entwicklung hervorgegangen. Über BDD bzw. Behavior Driven Development habe ich bereits gestern geschrieben.

Klassisch und fast schon nostalgisch hat man und praktiziert man die Entwicklung heute noch nach dem Wasserfall- oder dem V-Modell-Prinzip. Man entwickelt die Tests parallel zum und unabhängig vom zu testenden System oder sogar erst nachdem die Anwendung „fertiggestellt“ wurde. Aufgrund dieser Tatsache resultiert meist daraus, dass der Code schwer testbar ist und somit der Aufwand für die Tests verhältnismäßig hoch ausfällt. Darüber hinaus kommt es auch vor, dass die Tests nicht die gewünschten oder erforderlichen Testabdeckungen und Ergebnisse liefern, die man sich erhofft.

Dies kann unter anderem daran liegen, dass die fehlende oder mangelnde Testbarkeit des Systems auf die Nutzung von Fremdkomponenten zurückzuführen ist. Auch die Verweigerung einer Investition in nicht-funktionale Programmteile seitens der Entscheider bzw. Unternehmensführung kann ein Grund dafür sein. So im Sinne von, „Arbeit, von der man später im Programm nichts sieht, seien vergeudete Ressourcen.“ Die Erstellung von Tests unter Zeitdruck, rein um die gewünschte Testabdeckung zu erzielen ist ebenfalls ein Grund dafür. Nicht selten, ist es aber auch die Nachlässigkeit und mangelnde Disziplin der Entwickler bei der Testerstellung. An dieser Stelle sein auch das White-Box-Testing zu erwähnen, den ich aber in einem zukünftigen Beitrag thematisieren werde.

Die Methode der testgetriebenen Entwicklung versucht den Nachteilen entgegenzuwirken und dabei auch ein auf die Aufgabenstellung der Software besser angepasstes und wartbareres Softwaredesign zu liefern.

Alles in allem ist es eine Tatsache, dass man bei der Anwenung von testgetriebener Entwicklung im Schnitt bis zu 45 Prozent aller Fehler erkennen bzw. vermeiden kann. Im Vergleich dazu, werden beim reinen Einsatz von Unittests im Schnitt nur bis zu 30 Prozent der Fehler erkannt.

Wie funktioniert TDD?

Bei der testgetriebenen Entwicklung ist zwischen dem Testen im Großen (Integrationstests, Systemtests, Akzeptanztests) und dem Kleinen Modultests (Unit Tests) zu unterscheiden.

Testgetriebene Entwicklung mit Unit-Tests (Stichwort Tests First bzw. Middle-Out-TDD)

Man schreibt Unit-Tests in der Regel vor der eigentlichen Entwicklung der Anwendung. Es ist nicht festgelegt, ob der Entwickler, der die Implementierung vornimmt, auch die Unit-Tests erstellt. Es ist erlaubt, dass mehrere fehlschlagende Unit-Tests gleichzeitig existieren. Die Umsetzung des von einem Unit-Test geforderten Verhaltens in der Anwendung kann zeitlich verschoben werden.

Die Methode Tests First kann als Vorstufe der testgetriebenen Entwicklung betrachtet werden.

TDD nach Kent Beck

Man entwickelt Unit-Tests und die mit ihnen getesteten Units stets parallel. Die eigentliche Entwicklung erfolgt in kleinen, wiederholten Mikroiterationen. Eine solche Iteration, die nur wenige Minuten dauern sollte, hat drei Hauptteile, die man im englischen schlicht als Red, Green und Refactor bezeichnet.

1. Red: Schreibe einen Test, der ein neues zu programmierendes Verhalten (die Funktionalität) prüfen soll. Dabei fängt man mit dem einfachsten Beispiel an. Ist die Funktion schon älter, kann dies auch ein bekannter Fehler oder eine neu zu implementierende Funktionalität sein. Dieser Test wird vom vorhandenen Programmcode erst einmal nicht erfüllt und muss folglich fehlschlagen.
   
2. Green: Ändere den Programmcode mit möglichst wenig Aufwand ab und ergänze ihn, bis er nach dem anschließend angestoßenen Testdurchlauf alle Tests besteht.
   
3. Räume dann im Code auf (Refactoring): Entferne Wiederholungen (Duplizierten Code), abstrahiere wo nötig, richte ihn nach den verbindlichen Code-Konventionen aus. In dieser Phase darf kein neues Verhalten eingeführt werden. Nach jeder Änderung werden die Tests ausgeführt. Der Fehlschlag der Tests verbietet es, die offenbar fehlerhafte Änderung in den bereits genutzten Code zu übernehmen. Ziel des Aufräumens ist es, den Code schlicht, elegant und verständlich zu machen.

Diese drei Schritte wiederholt man so lange und so oft, bis die bekannten Fehler bereinigt sind, der Code die gewünschte Funktionalität liefert und dem Entwickler keine sinnvollen weiteren Tests mehr einfallen, die vielleicht noch scheitern könnten. Die so behandelte programmtechnische Einheit (Unit) wird dann als einstweilen fertig angesehen. Die gemeinsam mit ihr geschaffenen Tests werden beibehalten, damit auch nach künftigen Iterationen und Änderungen getestet werden kann, ob die schon erreichten Aspekte des Verhaltens weiterhin erfüllt werden.

Damit die – auch Transformationen genannten – Änderungen in Schritt 2 zum Ziel führen, muss jede Änderung zu einer allgemeineren Lösung führen. Sie darf also nicht etwa nur den aktuellen Testfall auf Kosten anderer behandeln. Tests, die immer mehr ins Detail gehen, treiben den Code so zu einer immer allgemeineren Lösung. Die Beachtung der Transformationsprioritäten führt dabei regelmäßig zu effizienteren Algorithmen und damit Anwendungen. Die konsequente Befolgung dieser Vorgehensweise ist eine evolutionäre Entwurfsmethode, indem jede der einzelnen Änderungen bzw. Iterationen das System von Natur aus weiterentwickelt.

Testgetriebene Entwicklung mit System- oder Akzeptanztests (Stichwort Outside-In-TDD)

Wie bereits erwähnt, entwickelt man Systemtests bei der testgetriebenen Entwicklung immer vor dem System selbst oder aber man erstellt zumindest das Konzept dafür. Aufgabe der Systementwicklung ist bei testgetriebener Entwicklung nicht mehr, wie klassisch, schriftlich formulierte Anforderungen zu erfüllen, sondern spezifizierte Systemtests zu bestehen.

Akzeptanztestgetriebene Entwicklung (ATDD)

ATDD ist zwar mit testgetriebener Entwicklung verwandt, unterscheidet sich jedoch in der Vorgehensweise von testgetriebener Entwicklung. Akzeptanztestgetriebene Entwicklung ist ein Kommunikationswerkzeug zwischen dem Kunden bzw. den Anwendern, den Entwicklern und den Testern. Es soll sicherstellen, dass die Anforderungen gut beschrieben sind. Akzeptanztestgetriebene Entwicklung verlangt keine Automatisierung der Testfälle, wenngleich diese für das Regressionstesten hilfreich sind. Die Tests bei akzeptanztestgetriebener Entwicklung müssen dafür auch für Nicht-Entwickler lesbar sein. Die Tests der testgetriebenen Entwicklung können in vielen Fällen aus den Tests der akzeptanztestgetriebenen Entwicklung abgeleitet werden.

Der Beitrag TDD – Test Driven Development – Qualitativ hochwertige Software von Anfang an erschien zuerst auf CEOsBay.

Die verhaltensgetriebene Entwicklung kombiniert die allgemeinen Techniken und Prinzipien von TDD. Unter Anderem auch mit Ideen aus dem bereichsgetriebenen Design, der objektorientierten Analyse und dem objektorientierten Design, um Softwareentwicklungs- und Managementteams gemeinsame Tools und einen gemeinsamen Prozess für die Zusammenarbeit bei der Softwareentwicklung zur Verfügung zu stellen.

So wie man die Softwareentwicklung sowohl von geschäftlichen Interessen als auch von technischem Verständnis voranbringt, setzt die BDD-Praxis den Einsatz spezieller Softwaretools zur Unterstützung des Entwicklungsprozesses voraus. Obwohl man diese Tools oft speziell für den Einsatz in BDD-Projekten entwickelt, kann man sie als spezialisierte Formen der Tools zur Unterstützung der testgetriebenen Entwicklung betrachten. Diese Tools dienen dazu, die allgegenwärtige Sprache, die ein zentrales Thema von BDD ist, zu automatisieren.

BDD wird weitestgehend durch die Verwendung einer einfachen domänenspezifischen Sprache (DSL = Domain-Specific-Language) mit natürlichen sprachlichen Konstrukten (z.B. deutsch- oder englischsprachige Sätze) erleichtert, mit denen man das Verhalten und die erwarteten Ergebnisse ausdrückt. Testskripte sind seit langem eine beliebte DSLs mit unterschiedlichem Grad an Raffinessen. BDD gilt als effektive technische Praxis, insbesondere wenn der „Problemraum“ des zu lösenden Geschäftsproblems komplex ist.

Wie funktioniert BDD?

Im Grunde genommen besteht Behavior Driven Development aus den folgenden Elementen:

• Starke Einbeziehung der Stakeholder in den Prozess durch sogenannte Outside-In-Softwareentwicklung. Diese ist fokussiert auf die Erfüllung der Anforderungen der Auftraggeber, der Enduser, des Betriebs und von Insidern.
• Textuelle Beschreibung des Verhaltens der Software und von Softwareteilen durch Fallbeispiele. Verwendung genormter Schlüsselwörter zur Markierung von Vorbedingungen, des externen Verhaltens und des gewünschten Verhaltens der Software.
• Automatisierung der Fallbeispiele unter Verwendung von Mock-Objekten zur Simulation von noch nicht implementierten Softwareteilen.
• Sukzessive Implementierung der Softwareteile und dem Ersetzen der Mock-Objekte.

Dadurch entsteht eine automatisiert prüfbare Beschreibung der zu entwickelnden Software, die jederzeit die Richtigkeit der bereits umgesetzten Teile der Software überprüfen lässt.

Wichtig ist hierbei, dass die Beschreibung nicht die Implementierung der Anwendung vorgibt, sondern den Zweck der Anwendung in Form von Anwendungsbeispielen.

Beim Behavior Driven Development werden die Anforderungen an die Software mittels Beispiele, sogenannten Szenarien beschrieben. Üblicherweise wird für die Beschreibung dieser Szenarien ein bestimmtes Format vorgegeben, damit später die automatisierte Überprüfung der Szenarien einfach umzusetzen ist. Eines dieser Formate ist die Beschreibungssprache „Gherkin“. Man kann es auch in verschiedenen Behavior-Driven-Development-Implementierungen verwenden. Diese Sprache gibt es sowohl mit englischen Schlüsselwörtern (Given, When, Then, And, …), deutschen (Gegeben, Wenn, Dann, Und, …) und in weiteren Sprachen. Mehr dazu in meinem Beitrag über Cucumber bzw. Gherkin.

Fazit

Behavior Driven Development (BDD) ist eine agile Softwareentwicklungs-Methode, die sich auf die Zusammenarbeit zwischen Entwicklern, Business Analysten und Kunden konzentriert, um sicherzustellen, dass die erstellte Software den Bedürfnissen der Anwender entspricht. BDD ist eine Erweiterung des Test Driven Developments (TDD) und legt den Schwerpunkt auf die Definition von klaren, verständlichen Anforderungen und Tests, die das Verhalten der Anwendung aus der Perspektive des Nutzers beschreiben. Durch die Verwendung von gemeinsamer Sprache und konkreten Beispielen kann man die Kommunikation zwischen den Stakeholdern verbessern und Missverständnisse vermeiden. Das Ergebnis ist eine höhere Qualität der Software, eine schnellere Markteinführung und eine höhere Kundenzufriedenheit.

Der Beitrag BDD – Behavior Driven Development – Software, die den Anforderungen der Kunden entspricht erschien zuerst auf CEOsBay.