Ein Angebot von

Warum Modultests unbeliebt sind und wie man sie rehabilitieren kann

| Autor / Redakteur: Mark Lambert * / Sebastian Gerstl

Modultests: Wenig geliebt, aber äußerst wertvoll, wenn es um saubern Quellcode und möglichst lückenlose Security im fertigen System geht.
Modultests: Wenig geliebt, aber äußerst wertvoll, wenn es um saubern Quellcode und möglichst lückenlose Security im fertigen System geht. (Bild: Shutterstock)

Für die meisten Entwickler sind Modultests nicht mehr als ein unvermeidbares Übel, das man einfach hinter sich bringen muss. Warum ist das so, und wie kann Softwareautomation Abhilfe bieten?

Die meisten Entwicklungsteams werden zustimmen, dass sie Modultests zwar nicht mögen, dass diese Tests aber tatsächlich nützlich sind. Denn sie unterstützen Entwickler, den von ihnen entwickelten Code wirklich zu verstehen, und schaffen ein solides Fundament für die Continuous-Testing-Pyramide (siehe Bild). Diese wiederum ermöglicht den Teams das Beschleunigen der agilen Entwicklung und reduziert gleichzeitig das Risiko, dass sich in späteren Phasen Fehler einschleichen.

Ich würde sogar noch einen Schritt weitergehen und sagen, schon allein das Erstellen eines Modultests ist eine nützliche Aktivität. Schließlich kann der Entwickler so seinen Code aus einem anderen Blickwinkel betrachten und im Prinzip eine zusätzliche Codeprüfung vornehmen. Führt man also einen Modultest durch, prüft man die Schnittstelle zur Funktionalität aus einer externen Perspektive. Es ist nützlich, sich dabei Fragen zu stellen wie:

  • Wie wird mein Code angewendet werden? Dies führt zu einer vereinfachten Schnittstelle und zu niedrigeren Kosten für die Pflege des Codes.
  • Was passiert, wenn ich ungültige Daten erhalte? Das Resultat ist ein robusterer, wiederverwendbarer Code.

Im Regelfall beschränken sich die Entwicklungsteams auf ein Minimum an Modultests oder lassen sie sogar ganz aus. Die Gründe hierfür liegen meist im Zwang zur Realisierung von immer mehr Funktionalität und in dem dafür entstehenden Zeitaufwand. Hinzu kommt darüber hinaus die Tatsache, dass das Erstellen sinnvoller Modultests in der Regel eine komplexe und zeitaufwändige Aufgabe ist.

Das Ende der Vorsätze, gute Modultests durchzuführen

Blickt man genauer hin, lässt sich dies in mehrere Argumente aufschlüsseln, die Entwickler gerne anführen und die der Akzeptanz der Modultests als zentrale Entwicklungs-Aktivität im Wege stehen:

  • Es ist schwierig, das zu prüfende Modul zu verstehen und zu initialisieren und/oder seine Abhängigkeiten zu isolieren.
  • Die Festlegung, was validiert werden muss, und das Definieren der richtigen Assertions (Zusicherungen) sind zeitaufwändige Aufgaben, die oft ein intelligentes ‚Rätselraten‘ erfordern.
  • Es ist viel manuelle Codierarbeit nötig – nicht selten mehr als für die ursprüngliche Implementierung eines bestimmten Features oder einer Verbesserung.
  • Es ist nicht übermäßig interessant. Entwickler wollen sich nicht als Tester betätigen, sondern ihre Zeit lieber in die Realisierung von mehr Funktionalität investieren.

Um hier Abhilfe zu schaffen, existieren auf dem Markt zahlreiche Tools, die Hilfestellung bei Modultests leisten können. Modultests und Assertion Frameworks bieten standardisierte Ausführungs-Formate (Junit) zur nahtlosen Integration in die CI-Infrastruktur (z. B. Jenkins, Bamboo, TeamCity). IDEs wiederum (wie z. B. Eclipse, IntelliJ) helfen beim Erstellen des Testcodes. Mocking-Frameworks wie beispielsweise Mockito oder PowerMock isolieren den Code von seinen Abhängigkeiten, und Code-Coverage-Tools (z. B. Emma, Cobertura, Clover) ermöglichen gewisse Einblicke darin, welcher Code ausgeführt wurde. Debugger schließlich geben den Entwicklern die Möglichkeit, die schrittweise Ausführung eines bestimmten Tests zu überwachen und zu inspizieren.

Leider jedoch sind alle diese Tools mit Mängeln behaftet, sodass die Entwickler immer noch auf Probleme stoßen. Hier einige Beispiele:

  • Die IDE hilft beim Erstellen eines Gerüsts für den Modultest, aber nicht beim Befüllen mit Inhalten. Um einen ausführbaren Test zu bekommen, muss der Entwickler also noch eine große Menge Code hinzufügen (Siehe Bild 2).
  • Um festzustellen, ob die richtigen Werte zugesichert wurden, sind die manuelle Definition von Assertions und die Durchführung von Tests notwendig.
  • Mocking-Frameworks bringen einen erheblichen Aufwand an manueller Codierung zum Instanziieren und Konfigurieren mit sich und erfordern Kenntnisse über ihre korrekte Anwendung.
  • Coverage-Tools bieten zwar Einblicke darin, welchen Code ein ausgeführter Test abgedeckt hat, doch das Laufzeitverhalten des Tests bleibt im Dunklen.
  • Debugger können für einen einzelnen Test verwendet werden, lassen sich aber nicht skalieren, um einen kompletten Testdurchlauf zu überwachen.

Insgesamt bringt das Erstellen eines Modultests also nach wie vor eine große Menge manueller, zeitraubender und häufig auch sterbenslangweiliger Arbeit mit sich, bevor man überhaupt darangehen kann, Geschäftslogik zu einem Test hinzuzufügen.

Softwaretest-Automatisierung: Lösung in Sicht

Zur Realisierung eines Tools, um die eben beschriebenen neuralgischen Punkte zu vermeiden, hat Parasoft auf die Softwaretest-Automatisierung gesetzt. Als Ergebnis lassen sich mit dem Unit Test Assistant (UTA) von Parasoft Jtest vollständig funktionsfähige Modultests erstellen – schnell und einfach auf Knopfdruck.

Zwar sind die mit dem UTA erstellten Tests ganz ‚normale‘ JUnits, aber die Lösung erledigt sämtliche Routinearbeiten. So richtet UTA das Test Framework ein, instanziiert die Objekte und konfiguriert Mocks (Attrappen) für entsprechende Objekte und Methodenaufrufe für die zu prüfende Methode. Diese JUnits lassen sich genau wie existierende Tests im Rahmen des gewohnten CI-Workflows ausführen. Führt der UTA aber eine JUnit (einschließlich der bestehenden Tests) aus, überwacht er den Test so, dass über die Codeabdeckungs-Zahlen hinaus eine Analyse geboten wird.

Durch das Analysieren des Tests zur Laufzeit kann der UTA eine Reihe von Empfehlungen geben – viele davon mit Quick Fixes (schnellen Lösungen), mit deren Hilfe sich mit einem Klick Abhilfemaßnahmen einleiten lassen, beispielsweise:

  • Markierung von Objektwerten, die sich geändert haben und zugesichert werden sollten.
  • Identifikation von Methodenaufrufen, die durch Attrappen ersetzt werden sollten, um den zu prüfenden Code besser zu isolieren.
  • Aufdeckung von Tests, die nach ihrer Ausführung ‚nicht aufräumen‘, sondern stattdessen eine potenziell instabile Testumgebung hinterlassen (beispielsweise durch die Nutzung von Threads, externen Dateien, statischen Feldern oder Systemeigenschaften).

Der Unit Test Assistant wurde entwickelt, um Modultests zu vereinfachen. Als ein auf Software Testing spezialisiertes Unternehmen weiß Parasoft, dass Modultests einen essenziellen Schritt bei der Entwicklung von Software darstellen, die sicher (im Sinne von ‚safe‘ und ‚secure‘), zuverlässig und von hoher Qualität ist.

Komplexität im Software Engineering, Teil 1

Komplexität im Software Engineering, Teil 1

05.01.18 - Wenn ich in meinen Vorträgen auf Kongressen in die Runde der Zuhörer die Frage stelle, wer NICHT vom Wachstum der Komplexität betroffen ist, bekomme ich lediglich vereinzelt ein oder zwei Meldungen. Wir können davon ausgehen, die Komplexität in unserer Gesellschaft wächst, und das sogar mit zunehmender Geschwindigkeit. lesen

Software-Design für gute Codequalität

Software-Design für gute Codequalität

17.11.17 - Guter Code ist Code, der offensichtlich korrekt ist. Offensichtlich korrekter Code ist einfach lesbar, einfach zu warten und einfach überprüfbar. Wie erstellt man also guten Code? lesen

* Mark Lambert ist Vice President Products bei Parasoft Inc. .

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45070683 / Test & Qualität)