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.

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.

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.

Cucumber wurde ursprünglich in der Programmiersprache Ruby für Ruby-Anwendungen geschrieben. In der Zwischenzeit unterstützt es aber auch andere Programmiersprachen wie Java und alle anderen auf der Java Virtual Machine gängigen Programmiersprachen sowie C++ und JavaScript. Darüber hinaus gibt es Projekte, die Cucumber noch für weitere Programmiersprachen zur Verfügung stellen und sich als Teil der Cucumber-Familie sehen. Darunter beispielsweise SpecFlow, eine Implementierung für C#.

Wie funktioniert Cucumber?

Wie auch bei den meisten anderen BDD-Frameworks werden in Cucumber Funktionalitäten mittels der Beschreibungssprache „Gherkin“ beschrieben. Gherkin verwendet natürliche Schriftsprache als Grundlage. Lediglich bestimmte Schlüsselwörter werden besonders behandelt.

Gherkin

Gherkin ist die Sprache, die Cucumber verwendet, um Testfälle zu definieren. Sie ist so konzipiert, dass sie sich nicht-technisch und für den Menschen lesbar gestaltet. Es beschreibt Anwendungsfälle in Bezug auf ein Softwaresystem. Der Zweck hinter der Gherkin-Syntax ist die Förderung verhaltensorientierter Entwicklungspraktiken in einem Entwicklungsteam, einschließlich Geschäftsanalysten und Managern. Sie zielt darauf ab, bereits in den ersten Phasen der Anforderungsdefinition durch die Geschäftsleitung und in anderen Phasen des Entwicklungslebenszyklus einer Anwendung feste, eindeutige Anforderungen durchzusetzen.

Syntax

Die Syntax ist ähnlich wie bei Python zeilenorientiert aufgebaut. Die Struktur einer Datei wird durch Leerzeichen und andere Steuerzeichen definiert. # wird als Zeilen bzw. Kommentarzeichen verwendet und kann an jeder beliebigen Stelle in einer Datei stehen. Anweisungen sind jede nicht leere und nicht kommentierte Zeile. Sie bestehen aus einem konkreten Gherkin-Schlüsselwort, gefolgt von einer Zeichenkette.

Alle Gherkin-Dateien haben die Dateierweiterung .feature. Sie enthalten eine einzelne Feature-Definition für das zu testende System und sind ein ausführbares Testskript.

Neben der Bereitstellung eines Skripts für automatisierte Tests ist die Syntax von Gherkin so konzipiert, dass sie eine einfache Dokumentation des zu testenden Codes ermöglicht. Gherkin unterstützt derzeit Schlüsselwörter in Dutzenden von Sprachen.

Schlüsselwörter der Gherkin Sprache

• Feature: Name bzw. die Bezeichnung des Features
• Rule: Regeln des Features
• Example oder Scenario: Die Bezeichnung des Szenarios (Beispielsweise „Die erfolgreiche Anmeldung mit gültigen Anmeldeinformationen.“)
• Given, When, Then, And, But für die steps (oder *)- Vorbedingungen (Gegeben sei), die Aktion, die ausgeführt wird bzw. die Erweiterung durch andere Schlüsselwörter um die Aktion die ausgeführt wird zu ergänzen bzw. zu erweitern. (Der User gibt beispielsweise seine Zugangsdaten, Username and Password ein), gefolgt von der erwarteten Reaktion des Systems (Beispielsweise die Nachricht, bei einem erfolgreichen Login.)
• Background – Ein Background ermöglicht es einem, den nachfolgenden Scenarios einen gewissen Kontext hinzuzufügen. Es kann einen oder mehrere Vorgegebene Schritte enthalten, die vor jedem Scenario aber nach jedem Before hook ausgeführt werden.
• Scenario Outline oder Scenario Template – Damit lässt sich dasselbe Szenario mehrmals mit unterschiedlichen Wertekombinationen ausführen.
• Examples oder Scenarios – Eine Scenario Outline muss einen oder mehrere Abschnitte mit Examples bzw. Scenarios enthalten. Sie dienen als Steps bzw. Interpretationsvorlage, die nie direkt ausgeführt werden. Stattdessen wird die Szenariogliederung einmal für jede Zeile mit den darunter liegenden Abschnitten von Examples ausgeführt.

Gherkin in deutscher Sprache

Um eine Funktionalität auf Deutsch zu schreiben, muss am Beginn des Features # language: de angegeben werden. Damit sind u.A. folgende deutsche Schlüsselwörter verfügbar:

• Funktionalität
• Grundlage
• Szenario
• Szenariogrundriss
• Beispiele
• Angenommen
• Gegeben sei
• Wenn
• Dann
• Und und Aber, sowie *

Die Command line (CL)

Cucumber verfügt über eine integrierte Kommandozeilenschnittstelle, die eine umfassende Liste von Anweisungen enthält. Wie die meisten Kommandozeilen-Tools bietet Cucumber die Option –help an, die eine Zusammenfassung der Befehle liefert, die diese Command Line akzeptiert.

$ cucumber --help
        -r, --require LIBRARY|DIR        Require files before executing the features.
        --i18n LANG                      List keywords for in a particular language.
                                         Run with "--i18n help" to see all languages.
        -f, --format FORMAT              How to format features (Default: pretty).
        -o, --out [FILE|DIR]             Write output to a file/directory instead of
        ...

Fazit

Gherkin ist nicht nur zum Schreiben von automatisierten Tests geeignet. Man kann Gherkin grundsätzlich auch dazu verwenden, um strukturierte Tests zu erstellen, die man später als Projektdokumentation verwendet kann. Erst die Eigenschaft, strukturiert zu sein, gibt uns die Möglichkeit zu automatisieren.

Sowohl die Sprache Gherkin wie auch das Tool Cucumber, bieten weitaus mehr Funktionalitäten, die ich hier nicht thematisiert habe. Zumal ich auch recht frisch in dieses Thema eingestiegen bin. So ist beispielsweise ein Datengetriebenes Szenario mithilfe von Tabellen möglich. Fernab können verschiedene Schritte, die im Prinzip das Gleiche tun, über Platzhalter definiert werden.

Um solche und weitere Vorteile zu nutzen, ist neben Cucumber oder anderen Testtools vor allem Disziplin beim Verfassen der Dokumentation bzw. der Gherkin Dokumente gefragt. Gleichzeitig müssen die formulierten Schritte präzise genug sein, um die gewünschten Verhaltensweisen ausreichend genau zu beschreiben. Ansonsten zerfällt die Abstraktion und Gherkin Dokumente werden lediglich zu etwas besser lesbaren Testskripten statt dem Ansatz des BDD zu folgen.

Cucumber lässt sich auch mit IntelliJ nutzen. Aber darüber gibt es dann in naher Zukunft einen weiteren Beitrag.

Der Beitrag Cucumber – Das kollaborative Tool für Behavior Driven Development erschien zuerst auf CEOsBay.