Hohe Testabdeckung ist kein Wert an sich, aber absolut nötig

Testgetriebene Entwicklung im E-Commerce [Gastbeitrag]
Kommentare

Im Handwerk sichert das Zusammenspiel zahlreicher Faktoren ein qualitativ hervorragendes Ergebnis: hochwertige Komponenten, eine saubere Verarbeitung, Wissen und Erfahrung sowie insbesondere das beständige Überprüfen der eigenen Arbeit sind mit die wichtigsten Faktoren. Bei der professionellen Softwareentwicklung, und dazu gehört eben auch die Realisierung einer E-Commerce-Plattform, ist das nicht anders. Warum gerade eine testgetriebene Entwicklung dabei so wichtig ist, erklärt der folgende Artikel.

Ein Jahr vor der Veröffentlichung des Apple II und 13 Jahre vor der Erfindung des Internets – damals als Software noch kein Massenphänomen war – machte sich Thomas J. McCabe bereits Gedanken über ihre Qualität. Er entwickelte die McCabe-Metrik, mit deren Hilfe auch heute noch die Komplexität von Software gemessen wird. Die sogenannte „zyklomatische“ Komplexität beschreibt die Einfachheit des analysierten Quellcodes.

Dabei werden die Anzahl der Verzweigungen der Prozeduren, aufgerufenen Funktionen oder auch konditionalen Abfragen gemessen. Hierbei handelt es sich um If-then-Anweisungen im Code, die beispielsweise die Ausführung einer Funktion auf eine bestimmte Gruppe beschränken (etwa die Ansprache „Lieber“ nur zu verwenden, wenn das Kundenattribut „männlich“ vorliegt). An solchen Stellen verzweigt sich der Fluss durch den Quellcode.

Je höher der Messwert, umso größer ist die Komplexität. Je höher die Komplexität, umso wahrscheinlicher ist das Auftreten von Fehlern und umso schwerer ist der Code zu verstehen. Bei einer Überschreitung eines Wertes von 50 bei der zyklomatischen Komplexität (CC-Wert 50) spricht man allgemein von einem Quellcode, der besonders fehleranfällig, nicht wartbar und nicht testbar ist. Dieser Code, bzw. die Software ist in ihrer Funktionalität also eingeschränkt. Etwas, das seine Funktion aber nicht richtig erfüllt, ist qualitativ mangelhaft.

Ungebrochene Aktualität

Zwar lässt sich der Entwicklungsalltag zu Zeiten von McCabe kaum noch mit dem heutigen Vorgehen vergleichen, die von ihm und seinen Nachfolgern entwickelten Metriken finden jedoch weiterhin Verwendung. Sie machen erkennbar, ob wichtige Qualitätskriterien beachtet wurden, und geben so auch Hinweise auf mögliche Geschäftsrisiken. Spätestens, wenn es um geschäftskritische Software geht, sollte eine qualitätsgetriebene Softwareentwicklung im Fokus eines jeden Auftraggebers stehen, um eine hohe Wartbarkeit und Zuverlässigkeit zu gewährleisten.

Test-driven Development ist gleich Qualität, aber nicht umgekehrt

Ein qualitativ hochwertiger Code muss nicht das Ergebnis einer qualitätsgetriebenen Softwareentwicklung sein. Der Code lässt sich natürlich auch im Nachhinein überprüfen und entsprechend anpassen. Die Kosten für ein solches Refactoring können aber je nach Umfang beachtlich sein… und sind in Relation immer wesentlich höher, als die Kosten für eine Entwicklung anhand qualitätssichernder Prinzipien. Beim Umgang mit Magento und PHP sind es – neben den übergreifenden eines Test-driven Developments – z. B. die der objektorientierten Programmierung, die sogenannten SOLID-Prinzipien.

SOLID – Was heißt das?

Das Akronym SOLID steht für folgende Vorgehensweisen und Paradigmen:

  • Single-Responsibility: Jede Klasse hat nur eine einzige Aufgabe
  • Open-Closed: Klassen, Module und Funktionen sollen erweiterbar sein
  • Liskovsches Substitutionsprinzip: Eigenschaften sollen auch für abgeleitete Klassen gelten
  • Interface-Segregation: Große Schnittstellen sind in mehrere kleine aufzuteilen
  • Dependency Inversion: Abhängigkeiten dürfen nur in einer eindeutig hierarchischen Struktur vorliegen 

Grundlagen eines Test-driven Developments

Die grundlegendste Anforderung bei einer testgetriebenen Entwicklung lässt sich eigentlich in einem Satz zusammenfassen: „Du sollst niemals Code schreiben, bevor ein Test nicht fehlschlug.“ Dieser Grundsatz lässt sich natürlich weiter ausdifferenzieren:

  • Ohne fehlgeschlagenen Test darf ein Entwickler also nicht anfangen zu coden.
  • D. h. zuerst muss ein Test geschrieben werden. Das bedeutet wiederum, dass man wissen muss, was man testen will, sprich, was in eine Funktion hineingehört und was dabei herauskommen soll.
  • Um das zu wissen, muss man sich zuvor mit der Systemarchitektur beschäftigt haben bzw. diese gegebenenfalls selbst definieren.
  • Aus Gründen der Ökonomie macht man sich daher Gedanken über bereits bestehende Lösungen, also über Design Patterns.
  • Aus den gleichen Gründen gilt es, die Tests sehr schmal zu halten: eine Funktion, eine Aufgabe, ein definierter Input und ein definierter Output. Das wirkt sich ebenfalls auf den eigentlichen Quellcode aus.

Die Einhaltung dieser Kriterien und Vorgehensweisen hat auch etwas mit Anspruch und Disziplin zu tun. Nicht umsonst spricht Robert C. Martin davon, dass “writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best.

Hilfestellung

Die größte Herausforderung bei einer testgetriebenen Entwicklung besteht aber nicht im Schreiben der Tests oder der Gestaltung eines Test-Workflows. Testing und Coding werden einfach auf möglichst kleine Softwareelemente heruntergebrochen (Units). Vielmehr geht es um das Konzipieren von Software nach gewissen Grundprinzipien, zum Beispiel SOLID.

Für die Praxis werden diese Meta-Prinzipien in Codestyles und Code-Konventionen zusammengefasst, Sammlungen von Regeln und Vorschriften für die Entwicklung leserlichen, verständlichen und übersichtlichen Quellcodes in einer bestimmten Programmiersprache. Zu diesen Regelsets gehören „Clean Code Rules“, „Code Size Rules“ oder auch „Naming Rules“. Doch deren formale Umsetzung kann nur gelingen, wenn man sich vorher intensiv mit den Meta-Prinzipien einer intelligenten Softwarearchitektur beschäftigt hat.

Warum ist das im E-Commerce so wichtig?

Die für die Umsetzung einer testgetriebenen Entwicklung wichtige Einhaltung dieser Prinzipien spielt auch für die Erweiterbarkeit einer Software eine große Rolle: Eine kluge Software-Architektur denkt das Thema Erweiterung per se mit.

Die klare Trennung der Module, die Eindeutigkeit der Beziehungen, die Entkopplung der Business-Logik usw. erleichtern nicht nur die Wartung und das Einspielen von Updates, sondern erlauben auch ein wesentlich wirtschaftlicheres Erweitern der Software. Neue Funktionen hängen nur von wenigen, bekannten Faktoren ab, was ihre Implementierung erleichtert. Wartung, Updates und das Erweitern eines Onlineshops machen aber den Löwenanteil der Entwicklungsleistungen innerhalb der Lebenszeit einer E-Commerce-Plattform aus.

e-commerce-pojekt

So sollte ein E-Commerce-Projekt aussehen: hohe Testabdeckung und eine permanent steigende Zahl an Testergebnissen; Quelle: netz98

Von einer intelligenten Softwarearchitektur hängt auch die Fähigkeit ab, Code umfangreich automatisiert zu testen. Besonderen Mehrwert bieten automatisierte Tests beim Thema Schnittstellen. E-Commerce-Systeme sind meist hoch vernetzt, etwa mit Marktplätzen und Shopping-Portalen, Serviceanbietern für Payment und Fullfilment oder den eigenen IT-Systemen und Lösungen (ERP, PIM, Newsletter-Marketing). Bei dateibasierten Schnittstellen ist etwa darauf zu achten, dass das korrekte Format erstellt wurde, aber auch der korrekte Inhalt.

Daher ist bei der Umsetzung solcher Architekturen der Test-Driven-Ansatz so wichtig: Nur so kann man nachweisen, dass zum einen die benötigten, richtigen und vollständigen Daten zur Verarbeitung geliefert wurden und zum anderen, dass daraus die richtigen Ausgaben erzeugt wurden. Also z. B. beim Datenaustausch mit einem ERP, ob etwa die Bestellnummer an der richtigen Stelle steht, in der für das Zielsystem richtigen Form und dass es überhaupt der richtige Wert ist. Bei einer Webservice-Schnittstelle zum Logistik-Partner testet man dann u. a. mit funktionalen Tests den Übertragungsweg über den eine Anfrage an ein externes System weitergegeben wird.

Fazit

All diese Tests gewährleisten, dass die Schnittstellen die in der Spezifikation vereinbarten Funktionen auch umsetzen. Die Vielzahl an Schnittstellen, Formaten und Spezifikationen machen manuelle Tests aber zu einem Ressourcengrab, der Verzicht auf Tests ist jedoch wie erwähnt ein Geschäftsrisiko. Nur automatisierte Tests – und die entsprechende Architektur der Software – garantieren, dass ein Shop stabil und einfach zu warten ist, also immer zur Verfügung steht und sich bei Bedarf einfach anpassen lässt. Und dass schließlich in der Endphase der Shopentwicklung nicht unzählige Personentage durch Bugfixing verschlungen werden und die Projektkosten in die Höhe schießen.

webinale 2017

Technische Suchmaschinenoptimierung 2017

mit Johannes Giesche (Trust Agents Internet GmbH)

Element Queries im Responsive Webdesign

mit Jonas Hellwig (kulturbanause)

Search Engine friendly Design: Von der Suche zur Konversion

mit Jens Fauldraht (takevalue Consulting GmbH)

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -