PHP ist nicht gerade bekannt dafür eine moderne Programmiersprache zu sein. Daher haben Konzepte wie TDD, BDD oder DDD auch nur langsam ihren Platz in der „mainstream“ PHP Community gefunden. Besonders Testing ist aber in den letzten Jahren immer wichtiger geworden und ist nicht mehr nur bei Software Entwicklern ein Must-Have.
In dieser Serie wollen wir uns Testing in PHP mal genauer ansehen. Was heißt Testing und TDD eigentlich überhaupt, wie funktioniert es, welche Begriffe gibt es und was kann man überhaupt testen sind die Fragen, die wir beantworten werden.
Bevor wir mit richtigen Tests loslegen, werde ich in der ersten Ausgabe der Serie auf die Testing Begriffe eingehen. Hier fängt es schon an unübersichtlich zu werden. Es gibt nämlich nicht nur dutzende Begriffe, sie werden auch unterschiedlich verwendet und in anderen Programmiersprachen anders verstanden. Deshalb räumen wir zu Beginn gleich auf und konzentrieren uns natürlich nur auf die Handhabung der Begriffe in der PHP Welt.
Wozu eigentlich Tests schreiben?
Zu Beginn klingt es vielleicht etwas ungewohnt. Ich schreibe einen Code der meinen eigentlichen Produktions-Code testet. Natürlich ist der anfängliche Aufwand dadurch auch gleich größer, denn mehr Schreiben heißt mehr Arbeit. Scheint so, ABER ist nicht so. Woran man nämlich dabei nicht denkt, ist die nachträgliche Fehlersuche. Wem ist es noch nicht passiert, dass er ein Feature live stellt und dabei Debug Output vergisst oder eine Mail-Funktion wird kurz deaktiviert und dann vergessen. Hier entstehen eine Vielanzahl an Fehlermöglichkeiten und diese sollten unbedingt vermieden werden.
Was einmal getestet ist funktioniert! Wird etwas am Code geändert, lässt man die Tests danach darüber laufen. Fehler wie oben erwähnt, würden gleich erkannt werden. Somit kommt nur Code live der auch funktioniert.
Kim Kardashian schläft nicht viel und daher sind ihr die wenigen Stunden sehr wichtig. Wer Tests schreibt kann Nachts beruhigt schlafen und muss sich keine Sorgen mehr um seine Applikationen machen.
TDD
TDD steht für Test-Driven-Development. Es ist ein Entwicklungsprozess bei dem Tests im Vordergrund stehen. Bevor der eigentlich Code geschrieben wird, wird zuerst ein Test dafür erstellt. Dabei ist man gezwungen umzudenken und sich schon vorher mehr Gedanken über die nächsten Zeilen zu machen.
Red, Green, Refactor
Der Prozess sieht demnach so aus, dass man zuerst einen Test schreibt. Diesen lässt man laufen und es wird hoffentlich ein Fehler geworfen, da der Test ohne den eigentlichen Code nicht funktionieren kann. Danach schreibt man den eigentlichen Code und der Test wird wieder gestartet und sollte jetzt eine Erfolgsmeldung zurückgeben. Man spricht hier auch von „Red Green Refactor“.
Dieser Prozess muss natürlich auch zu der Applikation und zum Programmierer passen. Nicht jeder bevorzugt diese Arbeitsweise, besonders in dieser strikten Form. Ich kenne jedoch keinen professionellen Programmierer der für größere Applikationen keine Tests empfiehlt. Aber auch schon bei kleineren Projekten können uns Tests bei der Programmierung helfen und die folgenden Testtypen sollte man daher kennen.
Kim würde auf jeden Fall nach dem TDD Prinzip arbeiten. Sie ist eine Perfektionistin und möchte ihre komplette Applikation durchgetestet haben.
Unit Tests
Unit Tests sind Tests, die sich auf kleine aber abgeschlossene Bereiche unseres Codes beziehen. Dabei konzentriert man sich auf nur eine einzige Sache die getestet werden soll. Ein perfektes Beispiel dafür sind Methoden. Ein Test würde kontrollieren ob der Rückgabewert bei bestimmten Methoden-Argumenten wie erwartet aussieht.
Der Begriff „abgeschlossen“ bezieht sich auch darauf, dass man versucht Code zu testen der nicht auf andere Funktionalitäten oder eine Datenbank angewiesen ist.
public function addOne($number) { return (int)$number + 1; }
Diese Funktion wäre perfekt für einen Unit Test. Sie hat genau eine Aufgabe und diese können wir gut testen. Ein Test könnte z.B. kontrollieren ob die Funktion bei einer Eingabe von 1 die 2 zurückgibt. Bei der Eingabe von 2 erwarten wir 3 usw.
Integration Tests
Diese Tests sind das Pendant zu den Unit Tests. Wir konzentrieren uns nicht mehr auf nur eine Sache, sondern testen die Kombination von mehreren Modulen. Die Funktion von unserem vorigen Unit Test wäre so ein Modul.
Ein klassisches Beispiel ist der Integration Test der Startseite einer Website. Hierbei wird kontrolliert, ob der Aufruf der Seite (z.B. liechtenecker.at) auch keinen Fehler zurückgibt. Mehrere Module müssen hier in Verbindung funktionieren, damit keine Fehlermeldung zu sehen ist.
Ein weiteres Beispiel wäre eine Applikation die einen Parameter von der URL nimmt und zu dieser Zahl Eins addiert. Bei dem Aufruf von „myapp.com/5“ möchten wir die Zahl 6 ausgegeben haben. Dieser Test würde unsere Funktion „addOne“ von vorher in Verbindung mit anderen Komponenten testen. Nur der Unit Test allein würde nicht ausreichen, denn es hilft uns leider nur sehr wenig wenn die Methode funktioniert, aber der Wert nicht ausgegeben wird.
Acceptance Tests
Wenn es ums Testing geht, hört man oft die Begriffe „low-level“ oder „high-level Tests“. „Low“ wären z.B. unsere Unit Tests, bzw. im speziellen unser Test einer Klassenmethode. Wir befinden uns hier tief im Inneren unserer Applikation.
Ein typischer „high-level“ Test wäre ein Acceptance Test. Hierbei geht es darum aus der Endnutzer Sicht zu testen. Ein Szenario könnte so aussehen, dass ich meine Zugangsdaten in ein Login-Formular eingebe und erwarte auf meiner Profilseite zu landen. Diesen Test könnte natürlich auch Kim oder jede andere Person selber durchführen, aber wir bevorzugen die automatisierte Version. Zeit ist Geld!
Bei einem Acceptance Test wird das Verhalten eines Nutzers komplett nachgestellt. Hier noch einmal das Login Beispiel in Einzelschritten:
- Ich befinde mich auf der Startseite
- Ich gebe in das Login-Formular meinen Namen und mein Passwort ein
- Ich klicke auf „Login“
- Ich befinde mich auf der Seite „…/profile“.
- Ich sehe eine „H1 headline“ mit dem Text „Willkommen zurück Christoph“.
So würde das Verhalten in einzelnen Aktionen aussehen und diese Aktionen können wir mit den richtigen Tools auch testen. Auf diese werde ich in einer weitern Ausgabe eingeben.
Fazit
Ich hoffe ich konnte euch das Thema Testing greifbar und schmackhaft machen. Aller Anfang ist schwer aber der Aufwand wird sich auszahlen. Da wir nun einen Überblick über das Thema haben, können wir in der nächsten Ausgabe der Serie direkt mit den ersten wirklichen Tests beginnen.
Kim Kardashian macht keine halbe Sachen. Sie wird daher natürlich auch die weiteren Artikel verfolgen um ein PHP Testing Profi zu werden. Fur uns ist jetzt schon klar, Kim würde in PHP Tests schreiben. Professionalität ist ihre Profession.
Du willst mit jemanden über das Thema plaudern?
Einen kostenlosen Termin mit CEO Susanne vereinbaren!UX Snacks Vol.09
That’s a wrap on UX Snacks 2024. Am 7. November hat die vierte und letzte Ausgabe in diesem Jahr stattgefunden und wir nehmen mit diesem Recap ganz viel positive UX-Energie mit ins neue Jahr. Und keine Angst: Schon bald verkünden wir die Daten für 2025.
Jetzt lesenFolge #62 mit Susanne Liechtenecker
In Folge 62 besinnt sich Susanne auf die Anfänge dieses Podcasts und begrüßt keinen Gast, sondern erzählt über das Buch "Jäger, Hirten, Kritiker" von Richard David Precht und warum es sie inspiriert hat.
Jetzt anhören