Test-Driven Development! Qualität & Sicherheit im E-Commerce

Im Handwerk sichern 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 die wichtigsten. Bei der professionellen Softwareentwicklung, und dazu gehört eben auch die Realisierung einer E-Commerce Plattform, ist das nicht anders. David Lambauer, Entwickler bei netz98, erklärt, warum Qualität in Software-Produkten so wichtig ist, und beschreibt einen Einstieg in das test-driven Development.

Relevanz

1976, ein Jahr vor der Veröffentlichung des Apple II und 13 Jahre vor der „Entdeckung“ des Internets, als Software noch lange kein Massenphänomen war, machte sich bereits jemand Gedanken über ihre Qualität. Thomas J. McCabe entwickelte die McCabe-Metrik, mit deren Hilfe auch noch heute die Komplexität von Software gemessen wird. Die sogenannte zyklomatische Komplexität beschreibt die Einfachheit des analysierten Quellcodes. Dabei werden die Anzahl Verzweigungen der Prozeduren, aufgerufenen Funktionen oder auch konditionalen Abfragen gemessen (das sind if-then-Anweisungen im Code, die beispielsweise die Ausführung einer Funktion auf eine bestimmte Gruppe beschränkten, 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 die Komplexität. Je höher die Komplexität, umso wahrscheinlicher sind Fehler und umso schwerer ist der Code zu verstehen. Bei einer Überschreitung der zyklomatischen Komplexität von 50 Bewertungspunkten (CC-Wert 50; CC steht für cyclomatic complexity) etwa 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 nicht richtig erfüllt, ist qualitativ mangelhaft.

Aktualität

Die Softwareentwicklung von damals hat nur noch wenig mit heutigen Standards zu tun, dennoch findet das Prinzip auch heute noch Anklang in der Entwicklung und neben der von McCabe entwickelten Metrik werden noch viele weitere verwendet. Die daraus berechneten Werte geben Auskunft über die Einhaltung entscheidender Qualitätskriterien – und  damit auch Hinweise für die Bewertung eines potentiellen Geschäftsrisikos. Und spätestens, wenn es um geschäftskritische Software geht, sollte eine qualitätsgetriebene Softwareentwicklung im Fokus eines jeden Auftraggebers stehen.

Testgetriebene Entwicklung

Ein qualitativ hochwertiger Code muss nicht das Ergebnis einer qualitätsgetriebenen Softwareentwicklung sein. Auch im Nachhinein kann natürlich der Code überprüft und entsprechend angepasst werden. 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 nach entsprechenden qualitätssichernden Prinzipien.

In unserem Fall – im Umgang mit Magento und PHP – die der objektorientierten Programmierung, der SOLID-Prinzipien, sowie eines Test-Driven Developments.

SOLID steht für das Folgende:

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

Test-Driven Development lässt sich in einem Satz zusammenfassen:

Schreibe niemals Code, bevor ein Test nicht fehlschlug.

Alles weitere erklärt sich aus den daraus folgenden Überlegungen:

• Ohne fehlgeschlagenen Test darf ich also nicht anfangen zu coden.
• Zuerst einen Test zu schreiben, bedeutet, dass ich exakt wissen muss, was ich in meine Funktionen hineingebe und was dabei heraus kommen soll.
• Um das zu wissen, muss ich mich wiederum mit der Systemarchitektur beschäftigen und diese ggf. selbst definieren.
• Dabei mache ich mir im Idealfall Gedanken über bereits bestehende Lösungen, also über Design Patterns.
• Weil ich eigentlich nicht viel Zeit mit dem Testen verschwenden will, fange ich auch an 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.

“Writing clean code is what you must do in order to call youself a professional. There is no reasonable excuse for doing anything less than your best.” (Robert C. Martin)

Die Herausforderung beim test-driven Development besteht nicht darin, dass Tests zu schreiben sind oder wie am besten ein Test-Workflow zu gestalten ist. Testing und Coding werden einfach auf möglichst kleine Softwareelemente heruntergebrochen (Units). Die Tests sind also am Ende des Tages nur Code, der den eigentlichen Code ausführt und die zurückgegebenen Werte überprüft.

Vielmehr geht es um das Konzipieren von Software nach gewissen Grundprinzipien, z. B. 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.

Ergebnisse

Ohne es also wirklich zu merken, verwende ich Entwurfsmuster für allgemeine Problemstellungen, nutze zuvor definierte Prinzipien wie das Single-Responsibility-Prinzip und obendrein ist der Code auch noch getestet!

Wie profitiert der Auftraggeber?

Nun, er erhält eine E-Commerce Plattform, deren Kern, die eigentliche Magento-Installation, in einem sehr hohen Maße durchs Tests abgedeckt ist, deren Funktionalität also sichergestellt ist. Die stabil und einfach zu warten ist, also immer zur Verfügung steht und sich bei Bedarf einfacher anzupassen ist. Die keine Performance-Probleme durch eine strukturelle Schwäche des Codes aufweist. Und die schließlich in der Endphase ihrer Entwicklung nicht unzählige PT aufgrund von Bugfixing verschlingt sowie die Projektkosten in die Höhe treibt. Diese Software ist kein Geschäftsrisiko.