Wann ist eine Software testbar? Testbarkeitskriterien im Komponententest

Conference Day - 21. Februar
 
14:10
14:40
 
Technologien und Tools
 
Seminarraum 1.812

Wann ist Code eigentlich testbar?
Um test first oder testgetrieben entwickeln zu können, müssen verschiedene Parameter zusammen treffen, wobei einer davon sicherlich die Einstellung des Entwicklers zu dieser Vorgehensweise ist. Agile Projekte tun einfach und entwickeln testgetrieben, weil sie eine hohe Softwarequalität als eine ihrer Kernaufgaben sehen. Sie verstehen es quasi als ihre Ehre und verfügen meist auch über junge, motivierte und gut geschulte Mitarbeiter. Klassische Projekte tun sich bisweilen etwas schwer, wobei der Gedanke von einer hohen Softwarequalität und automatisierten Unittests prinzipiell auch hier möglich ist. Grenzen werden aber im Bereich der Software selbst gesetzt, denn nicht jede Software ist gleich testbar. Das Schicksal einer schlechten Software kann hingegen aber auch sowohl agile, als auch klassische Projekte ereilen, denn eine agile Software ist auch nicht von sich aus gut testbar.

Es gibt aber messbare Kriterien, die über den Grad der Testbarkeit der Software Auskunft geben, die der Referent im Laufe der Jahre in verschiedenen Projekten entwickelt und angewendet hat. Diese Kriterien betreffen sowohl das Design, als auch die daraus entstehende Software. Der Referent hat zehn Kriterien aufgestellt, die dafür sorgen, dass der Code mit test first im Komponententest auch getestet werden kann. Diese werden mit praktischen Anwendungsbeispielen erläutert, die sofort auf jede objektorientierte Programmiersprache angewendet werden können. Dafür müssen ein paar Designprinzipien aufgebrochen werden, denn auch im Design werden schon Grundsteine für die Testbarkeit gelegt.

Mit diesen Kriterien können neue Softwareteile mit einer hohen Qualität gebaut werden - aber es gibt auch Möglichkeiten, alten Code sukzessive mit diesen Designpattern umzustellen und somit die Software zu verjüngen. Anhand eines Beispiels einer typischen legacy-Anwendung mit stark veraltetem Code werden Möglichkeiten aufgezeigt, die Wartung wieder zu ermöglichen und eine Testbarkeit des Codes herzustellen.

Dies ist insbesondere deswegen so wichtig, weil der Komponententest mit hunderten und tausenden Unittests die Grundlage für eine hohe Softwarequalität legt. Nur schwer lässt sich in den späteren Stufen “Qualität in die Software testen”.

Der Vortrag richtet sich schwerpunktmäßig an Entwickler und Softwaredesigner, kann aber sicherlich auch für IT-Test-nahe Personen und Projektleiter interessant sein.

Lawrence Kemnitz

Volkswagen Financial Services AG, Deutschland

2004 - 2007 Entwickler (ABAP) im Bereich Software-Architekturen

2007 Implementierung einer Plattform zur Testautomatisierung in SAP ABAP OO

2007 – 2014 Begleitung verschiedener Testautomatisierungsprojekte im IT-Test, schwerpunktmäßig Unittests in ABAP OO mit test driven development und test first.

2014 Implementierung einer neuen Version der Testautomatisierungsplattform, die als Server betrieben werden kann und alle Systeme des Unternehmens anbindet.

2017 Vortrag auf der iqnite-Konferenz: Automatisierung des Komponententests mit test driven development und test first am Beispiel von ABAP Unit

2014 – heute Rollout der Testautomatisierungsplattform im Unternehmen und Beratung in diversen Automatisierungsprojekten