Das V-Modell ist ein Prozessmodell in der Softwareentwicklung, das sich durch seine konsistente Systematik auszeichnet. Es hat seinen Ursprung in der Verifikation und Validierung von Software. In diesem Beitrag versuche ich die Besonderheiten dieses Modells zu erläutern, die es zu einer effektiven Methode für die Entwicklung qualitativ hochwertiger Software machen.

Per Definition handelt es sich um ein lineares Verfahren zur Softwareentwicklung, das die Beziehung zwischen jedem Entwicklungsstadium und seinem entsprechenden Teststadium definiert. Es legt die Abfolge der Entwicklungsschritte in einer Art V-Form dar, wobei die linke Seite des „V“ die Entwicklung und die rechte Seite die Integration und das Testen der Software darstellt.

Phasen im V-Modell

Die linke Seite des V-Modells beinhaltet die Anforderungsdefinition, System- und Software-Design sowie die Implementierung der Software. Jede Phase auf der linken Seite hat eine korrespondierende Phase auf der rechten Seite, in der das Testen durchgeführt wird.

1. Anforderungsdefinition: In dieser Phase werden die Anforderungen des Benutzers, des Systemanwenders oder des Kunden erfasst und dokumentiert. Dies bildet die Grundlage für die anschließende Entwurfsphase.
2. Funktionaler Systementwurf bzw. Systemdesign: Hier werden die Architektur und das High-Level-Design des Systems erstellt. Folglich die Anforderungen auf Funktionen und Dialogabläufe des neuen Systems abgebildet. Man kann auch von der Definition der Hauptkomponenten des Systems und ihre Interaktion sprechen.
3. Technischer Systementwurf bzw. Software-Design: In dieser Phase wird der detaillierte Entwurf der Software erstellt. Sie umfasst die Ausarbeitung der Einzelheiten der Software, die Erstellung von Algorithmen, Schnittstellen zur Systemumwelt und die Datenstrukturplanung. Man spricht auch von Komponenten, die möglichst unabhängig voneinander entwickelt werden können.
4. Komponentenspezifikation: In dieser Phase werden für jedes Teilsystem Aufgabe, Verhalten, innerer Aufbau und Schnittstellen zu anderen Teilsystemen definiert.
5. Programmierung: In dieser Phase wird der Code für die Software geschrieben. Sie basiert auf den Design-Entscheidungen, die in den vorherigen Phasen getroffen wurden. Jeder spezifizierte Baustein (Unit, Klasse usw.) wird in einer Programmiersprache (Siehe C++, Java, JavaScript) entwickelt (programmiert bzw. implementiert).

Auf der rechten Seite des V-Modells finden die entsprechenden Testphasen statt.

1. Komponenten- bzw. Unit-Test: Hier wird der Code auf Ebene der elementauf Fehler überprüft. Jede Funktion oder Methode wird einzeln getestet, um sicherzustellen, dass sie korrekt arbeitet.
2. Integrationstest: In dieser Phase wird überprüft, ob die verschiedenen Teile der Software richtig zusammenarbeiten.
3. Systemtest: Hier wird das gesamte System getestet, um sicherzustellen, dass es als Ganzes funktioniert.
4. Akzeptanztest bzw. Abnahmetest: Dieser Test wird durchgeführt, um zu überprüfen, ob das System die ursprünglich festgelegten Anforderungen erfüllt.

Vorteile des V-Modells

Die Vorgehensweise des V-Modells bietet verschiedene Vorteile. Durch die strikte Trennung von Entwicklungs- und Testphasen ist eine klare Struktur gegeben, die es den Entwicklern ermöglicht, sich auf eine Aufgabe zur Zeit zu konzentrieren. Zudem erlaubt das Modell eine frühe Fehlererkennung und -behebung, da jeder Entwicklungsschritt von einem spezifischen Test begleitet wird.

Fazit

Das V-Modell ist ein wichtiger Bestandteil der Softwareentwicklung. Durch seine systematische und strukturierte Herangehensweise hilft es Entwicklerteams, qualitativ hochwertige Software zu erstellen und gleichzeitig effizient zu arbeiten. Obwohl es nicht in jedem Entwicklungsprojekt zum Einsatz kommt, kann es in den richtigen Kontexten einen erheblichen Beitrag zur Verbesserung der Softwarequalität und -effizienz leisten. Insbesondere ist es nicht zu empfehlen, wenn Agilität und Flexibilität gefordert sind, wie beispielsweise in Start-ups oder bei der Entwicklung von Webanwendungen. Doch in Sektoren, in denen Robustheit, Sicherheit und Zuverlässigkeit der Software von zentraler Bedeutung sind, hat sich das V-Modell als äußerst wertvoll erwiesen.

Der Beitrag V-Modell in der Softwareentwicklung – Leitfaden erschien zuerst auf CEOsBay.

Was ist Jasmine?

Jasmine ist ein beliebtes Open-Source-Framework für Behavior-Driven Development (BDD) Tests in JavaScript. Man verwendet es hauptsächlich, um das Verhalten von JavaScript-Code durch das Schreiben von Test-Spezifikationen zu überprüfen. Jasmine bietet eine saubere, leicht verständliche Syntax und ermöglicht Entwicklern, ihre Tests unabhängig von ihrer Implementierung auszuführen. Dadurch können sie schnell und effizient sicherstellen, dass ihr Code wie erwartet funktioniert.

Vorteile:

• Einfachheit: Man hat Jasmine entwickelt, um leicht verständlich und zugänglich für Entwickler zu sein. Die Test-Syntax ist klar und einfach, sodass selbst Entwickler, die neu in der Testautomatisierung sind, schnell damit arbeiten können.
• Unabhängigkeit: Jasmine ist unabhängig von anderen JavaScript–Frameworks, Browsern und DOM-Manipulationsbibliotheken, was bedeutet, dass man es praktisch jedem JavaScript-Projekt verwenden kann, unabhängig von der verwendeten Technologie.
• Flexibilität: Entwickler können Jasmine für Unit-Tests, Integrationstests und sogar für End-to-End-Tests verwenden. Dies gibt ihnen die Möglichkeit, das gesamte Verhalten ihrer Anwendung mit einem einzigen Tool abzudecken.

Wie funktioniert Jasmine?

Jasmine basiert auf einer Hierarchie von Suites und Specs. Suites sind Gruppen von verwandten Tests, während Specs einzelne Testfälle sind. Diese Hierarchie ermöglicht es Entwicklern, ihre Tests klar zu strukturieren und den Code leicht zu organisieren.

Es verwendet das „describe“-Konstrukt, um Test-Suites zu definieren. Jede Suite kann mehrere Test-Spezifikationen (Specs) enthalten, die mit dem „it“-Konstrukt definiert werden. Diese Specs enthalten Erwartungen (Expectations) in Bezug auf das zu testende Verhalten des Codes.

Ein einfaches Beispiel für eine Jasmine Test-Suite sieht wie folgt aus:

describe("A suite is just a function", function() {
  let a;

  it("and so is a spec", function() {
    a = true;

    expect(a).toBe(true);
  });
});

oder

describe('Array', () => {
  describe('#indexOf()', () => {
    it('sollte -1 zurückgeben, wenn der Wert nicht im Array vorhanden ist', () => {
      expect([1, 2, 3].indexOf(4)).toBe(-1);
    });
  });
});

Integration in die Softwareentwicklung

Man kann Jasmine problemlos in moderne JavaScript-Projekte und Build-Tools integrieren. Mit Integrationen für Tools wie Grunt, Gulp und Webpack lässt es sich nahtlos in bestehende Entwicklungsprozesse einfügen. Darüber hinaus gibt es auch Jasmine-Plugins für gängige Entwicklungsumgebungen wie Visual Studio Code oder IntelliJ, die das Schreiben und Ausführen von Tests noch einfacher und bequemer gestalten.

Man kann es auch mit anderen Testing-Tools und Libraries kombinieren, um noch umfassendere Testlösungen zu schaffen. Beispielsweise kann man es mit Karma (einem JavaScript-Test-Runner) verwenden, um Tests in verschiedenen Browsern auszuführen, oder mit Protractor für End-to-End-Tests in Angular-Anwendungen.

Best Practices für Jasmine-Tests

Um das Beste aus Jasmine herauszuholen und effektive Tests zu erstellen, sind hier einige bewährte Vorgehensweisen:

• Klare Testbeschreibungen: Man sollte aussagekräftige und präzise Beschreibungen für Suites und Specs verwenden. Dies erleichtert das Verständnis des Testzwecks und die Identifizierung von Fehlern.
• Kleine, fokussierte Tests: Es ist ratsam, Tests zu schreiben, die nur eine Funktion oder ein Verhalten testen. Dies erleichtert das Auffinden und Beheben von Fehlern, da man dadurch genau im Blick behält, welcher Teil des Codes betroffen ist.
• Testabdeckung: Man sollte sicherstellen, dass man eine ausreichende Testabdeckung für den Code hat. Dies bedeutet, dass man alle wichtigen Funktionen und Szenarien in den Tests berücksichtigt.
• Mocking und Spies: Es ist zu empfehlen, Mock-Objekte und Spies zu verwenden, um externe Abhängigkeiten zu isolieren und den Testfokus auf den zu testenden Code zu richten. Jasmine bietet dafür eingebaute Funktionen wie createSpy und spyOn.
• Regelmäßige Testausführung: Man sollte die Tests regelmäßig ausführen, um sicherzustellen, dass Änderungen im Code nicht zu unerwarteten Fehlern führen. Daher ist es ratsam, Jasmine in den Continuous Integration (CI) bzw. Continuous Deployment (CI/CD) Prozess integrieren, um automatisch Tests auszuführen, sobald man Codeänderungen vornimmt.

Fazit

Jasmine ist ein leistungsstarkes und vielseitiges Framework für das Testen von JavaScript-Anwendungen. Mit seiner klaren Syntax, Flexibilität und Integration in moderne Entwicklungsprozesse ist es ein unverzichtbares Werkzeug für jeden JavaScript-Entwickler. Durch die Befolgung der Best Practices und die regelmäßige Ausführung von Tests können Entwickler sicherstellen, dass ihr Code zuverlässig und fehlerfrei funktioniert. Insgesamt trägt Jasmine dazu bei, die Qualität von JavaScript-Anwendungen zu verbessern und die Entwicklungszeit zu reduzieren.

Der Beitrag Jasmine – JavaScript Testautomatisierung erschien zuerst auf CEOsBay.

Was ist ein Test-Harnisch?

Ein Test-Harnisch (engl. test harness) ist ein Framework oder eine Sammlung von Tools, die dazu beitragen, das Testen von Softwareanwendungen zu automatisieren, zu koordinieren und zu überwachen. Im Wesentlichen stellt ein Test-Harnisch eine Umgebung bereit, in der Entwickler und Tester den Code einer Anwendung testen und sicherstellen können, dass er korrekt funktioniert und die Anforderungen erfüllt. Man kann Test-Harnische sowohl für manuelles als auch für automatisiertes Testen verwenden.

Funktionsweise eines Test-Harnisch

Ein Test-Harnisch besteht aus vier Hauptkomponenten:

1. Testtreiber: Der Testtreiber ist für die Ausführung der Tests verantwortlich. Er stellt die Schnittstelle zur Verfügung, über die die Tester die Testfälle ausführen und die Ergebnisse erfassen können.
2. Testdaten: Testdaten sind die Eingaben, die man während des Testprozesses verwendet. Sie bestehen in der Regel aus verschiedenen Datentypen, die man verwendet, um die verschiedenen Funktionen und Komponenten der Anwendung zu testen.
3. Testskripte: Testskripte sind Skripte, die den Testprozess automatisieren. Sie enthalten Anweisungen, wie die Tests ausgeführt und die Analyse der Ergebnisse stattfinden soll.
4. Testergebnisse: Testergebnisse sind die gesammelten Informationen, die aus dem Testprozess resultieren. Sie enthalten Daten über die Leistung der Anwendung, Fehler, die während des Testprozesses aufgetreten sind, und Informationen über die Korrektheit der Funktionen.

Vorteile von Test-Harnischen

• Automatisierung: Test-Harnische automatisieren den Testprozess und reduzieren so den Zeitaufwand und die Mühe, die mit manuellem Testen verbunden sind. Dies ermöglicht es Entwicklern und Testern, sich auf die Analyse der Testergebnisse und die Verbesserung der Softwarequalität zu konzentrieren.
• Wiederverwendbarkeit: Test-Harnische ermöglichen es, Testfälle und Testdaten wiederverwendbar zu gestalten, sodass man sie in verschiedenen Projekten und Anwendungen einsetzen kann.
• Vereinfachung: Test-Harnische vereinfachen den Testprozess, indem sie alle Testaktivitäten zentralisieren und eine einheitliche Testumgebung bereitstellen.
• Effizienz: Test-Harnische steigern die Effizienz des Testprozesses, indem sie die Testabdeckung erhöhen, den Testaufwand reduzieren und eine schnellere Fehlerbehebung ermöglichen.
• Kontinuierliche Integration: Test-Harnische unterstützen kontinuierliche Integration (CI) und kontinuierliche Bereitstellung (CD) in der Softwareentwicklung, indem sie die automatisierte Ausführung von Tests bei jedem Commit oder Build sicherstellen. Siehe hierzu den Beitrag über CI/CD.
• Berichterstattung und Analyse: Test-Harnische bieten umfangreiche Berichtsfunktionen, die es Entwicklern und Testern ermöglichen, den Fortschritt und den Status der Tests zu überwachen, Fehler und Schwachstellen schnell zu identifizieren und fundierte Entscheidungen über die Softwarequalität zu treffen.

Gängige Test-Harnisch-Tools in der Softwarebranche

Es gibt viele Test-Harnisch-Tools und Frameworks auf dem Markt, die verschiedene Programmiersprachen und Anforderungen unterstützen. Einige der bekanntesten sind:

JUnit: JUnit ist ein weit verbreitetes Testframework für Java-Anwendungen, das Test-Harnisch-Funktionalitäten wie Testausführung, Testdatenverwaltung und Ergebnisberichterstattung bietet.

TestNG: TestNG ist ein Testframework für Java-Programme, das auf JUnit basiert und erweiterte Funktionen wie Paralleltestausführung, Testkonfiguration und flexible Testskripterstellung bietet.

NUnit: NUnit ist ein Testframework für .NET-Anwendungen, das Test-Harnisch-Funktionen wie Testausführung, Testdatenverwaltung und Berichterstattung bietet.

Pytest: Pytest ist ein Testframework für Python-Anwendungen, das Test-Harnisch-Funktionalitäten wie Testausführung, Testdatenverwaltung und Ergebnisberichterstattung bietet.

Jasmine: Jasmine ist ein Testframework für JavaScript-Anwendungen, das Test-Harnisch-Funktionalitäten wie Testausführung, Testdatenverwaltung und Ergebnisberichterstattung bietet.

Fazit

Test-Harnische spielen eine entscheidende Rolle in der Softwareentwicklung, indem sie den Testprozess automatisieren, vereinfachen und effizienter gestalten. Durch den Einsatz von Test-Harnischen können Entwickler und Tester sicherstellen, dass ihre Anwendungen die gewünschte Qualität erfüllen und potenzielle Fehler frühzeitig identifiziert und behoben sind, bevor der Release stattfindet. Mit der wachsenden Anzahl von Test-Harnisch-Tools und Frameworks auf dem Markt können Entwickler und Tester leicht eine Lösung finden, die ihren spezifischen Anforderungen und Projektzielen entspricht.

Der Beitrag Test-Harnisch – Qualität und Zuverlässigkeit von Anfang an durch effektive Teststrategien 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.

JUnit wird zur Kompilierzeit als JAR gelinkt. Bei einem JAR handelt es sich um ein Java Archiv (umgangssprachlich wegen der Dateiendung auch JAR-Datei genannt) dient der Gliederung, Verteilung und Bereitstellung von Klassenbibliotheken und ausführbaren Programmen, die in der Programmiersprache Java erstellt wurden. Technisch ist es eine komprimierte Datei im ZIP-Format. Das Archiv enthält kompilierte Java-Klassen (Bytecode) und ggf. weitere Ressourcen. In der Regel umfasst es auch eine oder mehrere Dateien mit Metadaten. Diese haben fest vorgegebene Namen und Strukturen und liegen im Verzeichnis META-INF. Wie es genau funktioniert, schreibe ich in einem zukünftigen Beitrag. Auf jeden Fall kann man sich die Kurzbezeichnung des Archivs als Wortspiel mit dem englischen Wort jar (deutsch: „Gefäß“) ganz gut merken.

Die neueste Version des Frameworks, JUnit 5, befindet sich im Paket org.junit.jupiter. Die Vorgängerversionen JUnit 4 und JUnit 3 waren unter den Paketen org.junit bzw. junit.framework zu finden.

Eine im Jahr 2013 durchgeführte Umfrage unter 10.000 auf GitHub gehosteten Java-Projekten ergab, dass JUnit (gleichauf mit slf4j-api) die am häufigsten eingebundene externe Bibliothek ist. Jede Bibliothek wurde von 30,7 % der Projekte verwendet.

Wie funktioniert JUnit?

Ein JUnit-Test kennt nur zwei Ergebnisse: Entweder der Test gelingt (dann ist dieser „grün“) oder er misslingt (dann ist dieser „rot“). Das Misslingen kann als Ursache einen Fehler (Error) oder ein falsches Ergebnis (Failure) haben. Beides signalisiert via Exception (Eine Ausnahmesituation, normalerweise durch Fehler hervorgerufen). Der Unterschied zwischen den beiden Begriffen liegt darin, dass man Failures erwartet, während Errors eher unerwartet auftreten. 

Technisch betrachtet, sind Failures mittels einer speziellen Exception namens AssertionFailedError gekennzeichnet. Die Interpretation aller übrigen Exceptions erfolgen vom JUnit-Framework durch Errors.

JUnit im Softwareentwicklungsprozess

JUnit ist ein wichtiges Hilfsmittel im Extreme Programming und unterstützt in diesem Zusammenhang die Idee des Extreme Testing. Als Programmierer schreibt man zuerst einen automatisch wiederholbaren (JUnit-)Test und dann den zu testenden Code.

Der Test selbst ist ebenfalls ein Stück Software und ebenso wie der zu testende Code ist dafür die Programmierung notwendig.

Wenn man zu einem späteren Zeitpunkt den Code eines anderen Programmierers zum Ändern beabsichtigt, so ruft man zuerst alle JUnit-Tests auf, um sich zu vergewissern, dass der Code vor der Änderung fehlerfrei ist. Dann führt man die Änderung durch und ruft die JUnit-Tests erneut auf. Misslingen diese, so hat man die Erkenntnis, dass man selbst Fehler gemacht hat und muss diese korrigieren. Dieser Zyklus wiederholt sich so lange, bis alle JUnit-Tests wieder fehlerfrei durchlaufen.

Dieses Verfahren wird auch „testgetriebene Entwicklung“ (englisch test-driven software development) genannt und zählt zu den agilen Methoden. Die Idee dabei ist, fehlerarmen Code zu erzeugen, indem man nichts implementiert, was man nicht auch testet. Entstehen Testfälle erst nach der Entwicklung des Codes, so ist die Wahrscheinlichkeit höher, wichtige Testfälle zu übersehen. Doch darüber habe ich bereits hier einen Artikel geschrieben.

Plugins und Erweiterungen für JUnit

Eine Implementierung von JUnit für Jakarta EE ist Cactus (ehemals J2EEUnit) aus dem Jakarta-Projekt. Seit Java EE 5 haben sich sogenannte Out-of-container-Frameworks (zum Beispiel EJB3Unit) etabliert, die eine Ausführung von Tests außerhalb eines Containers erlauben.

Erweiterungen für JUnit dienen in der Regel für den Einsatz in spezifischen Bereichen (beispielsweise httpsUnit für Webentwicklung, DBUnit für Datenbankentwicklung). Darüber hinaus gibt es noch Plugins für Entwicklungsumgebungen, die den Einsatz innerhalb der Entwicklungsumgebung ermöglichen beziehungsweise erweitern (beispielsweise Infinitest für kontinuierliches Testen oder DJUnit für Berechnung der Code-Abdeckung, englisch Code Coverage, der Tests).

Testabdeckung

Bei der Testabdeckung geht es um das Verhältnis an tatsächlich getroffenen Aussagen eines Tests gegenüber den theoretisch möglich treffbaren Aussagen bzw. der Menge der gewünschten treffbaren Aussagen. Die Testabdeckung spielt als Metrik zur Qualitätssicherung und zur Steigerung der Qualität insbesondere im Maschinenbau und der Softwaretechnik eine große Rolle.

Die Testabdeckung lässt sich durch eine Erhöhung der Zahl an Messungen, Stichproben und Testfällen verbessern. Begrenzt wird die Testabdeckung in der Praxis jedoch durch die Kosten, die mit jedem Test verbunden sind. Doch dies ist ein komplexes Thema, welches ich gerne in einem separaten Beitrag thematisiere.

Fazit

JUnit ist ein einfach zu benutzendes und leichtgewichtiges Framework für die Entwicklung von Softwaretests. Eine Integration in verschiedene IDE’s ist möglich. Dies thematisiere ich aber in den Artikeln zu den einzelnen IDE’s. Diese verlinke ich dann selbstverständlich auch hier. Die Ausführung einzelner Tests oder kompletter Testsuiten ist im Entwicklungsprozess jederzeit möglich. Nur das Programmieren der Tests kann man damit naturgemäß nicht leisten. Jedoch ist die Einstiegshürde für einen relativ guten Entwickler minimal. Es ist dabei sehr zu empfehlen, möglichst frühzeitig mit der Erstellung von Tests zu beginnen! In der Literatur beginnt die Erstellung der Tests, besonders im agilen Umfeld. Zeitgleich mit der Entwicklung selbst. Sie sind der wichtigste Bestandteil der Qualitätssicherung. Insbesondere spätere Änderungen an der Software im Rahmen funktionaler Erweiterungen oder eines Refactorings sind ohne vorhandene Regressionstests oftmals gar nicht durchführbar.

Der Beitrag JUnit – Framework für automatisierte Tests und Qualitätssicherung erschien zuerst auf CEOsBay.