Kategorie: PHP

In PHP – wie natürlich auch in anderen Programmiersprachen – gibt es verkürzte truthy-Prüfungen. Ob, wie und wann man sie einsetzt muss aber genau überlegt sein. Das hilft am Ende nicht nur der Lesbarkeit sondern vermeidet auch Bugs, die auf Grund falsch gedachter oder vermeintlich logischer Prüfungen aufkommen.

(mehr …)

Vor einiger Zeit berichteten wir schon mal darüber, dass wir angefangen haben, PHPUnit-Tests zu verwenden. Inzwischen ist das fast schon ein Standard bei uns geworden – Zeit nochmal einen Einblick in etwas Spannendes zu geben…

Am Anfang steht natürlich immer die Frage: Was teste ich und wie?

Ein Test existiert schließlich nicht nur, damit am Ende alles schön grün aussieht. Vielmehr geht es darum, Schwachstellen, Edge‑Cases und unerwartete Situationen vor der Produktivsetzung abzufangen.

Die Erwartungshaltung ist klar

Ich schreibe einen Test, lasse ihn laufen und arbeite mich durch die Fehler, bis alles grün ist. Wenn ich gut bin, geht das schnell. Wenn ich schlecht bin oder Folgefehler auftreten, dauert es eben länger.

Und natürlich bringt mir ein Testpaket nur etwas, wenn ich mich nicht selbst belüge. Also: keine „nur einfachen Tests“, sondern Dinge, die realistisch auftreten können. Ein paar Beispiele:

• Nachname bleibt in einem Anmeldeformular unbelegt
• Telefonnummern in verschiedenen Schreibweisen -> wichtig! Die Frage hier ist kann mein Setup damit umgehen
• vielleicht eine nicht konforme Emailadresse
• bei API Routen und Co. durchaus mal Testen mit gültigem Auth, ungültigem Auth und keinem Auth. Kommt bei ungültigem und keinen Auth z.B. ein passender 401 bzw. 403 zurück? (Hier gern auch ein Hinweis auf unseren Artikel zum HTTP 401 vs. 403)

Gerade letzteres ist vielleicht etwas, auf das man nicht zwingend direkt kommt. Aber gerade solche Dinge sind auch wichtig, weil sie in der Realität ein Einfallstor liefern. Eine API Route die unautorisierte Zugriffe erlaubt und vielleicht sogar noch wilde Daten rausgibt – absolut undenkbar.

Aber muss man dafür immer gleich eine neue Testreihe schreiben?

Nicht unbedingt! Wir hatten zu Beginn der Entwicklung hier erst mal die API Route lokal ohne Auth hinterlegt. Das ist unsere modale Vorgehensweise: Schritt für Schritt und immer nach dem Credo Form follows function!

Was wir dann gemacht haben? Naja nachdem wir soweit waren das alle Tests „grün“ waren haben wir die Auth-Middleware aktiviert. Und dann? Einfach die Tests nochmal ausgeführt.

Natürlich waren alle Tests rot und das war auch erwartbar. Das war hier aber auch das Ziel – so konnten wir ohne neue Tests direkt sagen: Die Auth funktioniert, die Routen liefern korrekt ihr 401 zurück..

Also ja, unsere Tests waren rot.
Aber nein, das ist nicht schlimm.
Es war erwartbar – und in diesem Moment genau das, was wir wollten.

In PHP werden natürlich auch Fehler behandelt. Wenn man kritische Fehler nicht abfängt, wandern sie weiter nach oben bis das Script irgendwann eben abbricht. Fast jeder Entwickler dürfte schon einmal eine fatal error message erhalten haben. Oder falls der Server nicht ganz so auskunftsfreudig ist – was natürlich auf Grund der Sicherheit einer Seite begrüßenswert ist – dann eben einfach nur einen 500 internal Server error.

Beides trägt jetzt in der Regel in Produktivsystemen nicht gerade zur Begeisterung bei. Deswegen könnte der ein oder andere auch schon mal auf die Idee kommen um seinen Code einen try…catch Block zu bauen. Das bietet sich gerad bei potentiell sehr fehleranfälligen Programmpassagen an, hat aber manchmal noch zur Folge, dass der Fehler trotzdem auftritt. Das liegt daran das meistens dann eine solche Struktur genutzt wird:

try
{
   echo 50/0;
}
catch (Exception $e)
{
   echo "Division durch null ist nicht erlaubt!";
}

Das Problem dabei: Nicht alles was auftauchen kann ist auch Exception. Eigentlich ist eine Exception eher sowas wie ein Spezialfall für einen Fehler der auftauchen kann. Deswegen sollte man in einem solchen Fall das ganze besser so aufbauen:

try
{
echo 50/0;

}
catch (Throwable $e)
{
   echo "Division durch null ist nicht erlaubt!";
}

Denn alles was auftreten könnte ist auf jeden Fall ein Throwable. Hier wird es jetzt korrekt abgefangen und das Programm steigt nicht mehr aus. Natürlich lässt sich das noch verfeinern und erhebt keinen Anspruch auf Vollständigkeit, kann aber in manchen Situationen die Rettung sein…

PHPUnit-Tests gibt es schon seit über 20 Jahren. Bisher haben wir aber für unsere Entwicklungen eher auf „klassische“ Tests gesetzt. Heißt: Wir haben eine Software geschrieben und diese dann auf einem Testsystem „live“ ausprobiert. Um unsere Softwarequalität aber zu steigern und gleichzeitig Programmierstandards zu pflegen haben wir beschlossen in Zukunft bei der PHP-Entwicklung auch auf PHPUnit-Tests zu setzen. Ein erster Erfahrungseinblick.

Ausgangssituation

Wir hatten sowieso gerad ein neues Projekt am Start – diesmal wieder die Entwicklung eines WordPress-Plugins – und Ende letzten Jahres gerade auf der betterCode()-Konferenz für den Bereich PHP nochmal oder wieder von PHPUnit als „Test-Suite“ gehört. Da ja Stillstand bekanntlich den Tod bedeutet haben wir also mutig beschlossen, unsere Softwarequalität mithilfe dieses Tools einmal gehörig voranzubringen.

Natürlich behalten wir auch unsere bisherige Testmodalität mit der Testinstallation bei. Schließlich soll ja auch das Aussehen und die Funktionalität im Browser getestet werden. Die PHPUnit-Tests werden wir aber zukünftig verstärkt einsetzen um bereits vorab generelle Tests aufzubauen, die einfach verhindern, dass wir schon mit ganz rudimentären Fehlern an den Start gehen, wie z.B. ein vergessenes Semikolon am Ende oder eine zu viel geöffnete oder geschlossene Klammer…

Also wir hatten ein brandneues Projekt mit ohne irgendwas. Lokal haben wir einen Apache am Laufen und auch einen MariaDB-Server. Etwas googlen brachte uns dann noch den Hinweis, das es auch für WordPress eine Art „development“ Zweig gibt, mit dem man dann auch in PHPUnit testen können soll. Gesagt getan…

Einrichten und erst mal Testen der Testumgebung

Ja richtig: Bevor man sowas nutzen kann muss man das ja erst mal einrichten. Wir haben also erstmal das WordPress-Verzeichnis hingestellt und dann ging der Spaß auch schon los: Zum Einrichten hat uns das große Internet verraten, dass wir vermittels npm und grunt das ganze so aufsetzen können, dass es für unsere Unit-Tests läuft. Das war aber mal gar nicht so einfach. Es gab node und npm aber wir mussten zunächst die Pfade in die Umgebungsvariablen bringen bzw. verbessern, da node und npm ursprünglich über Visual Studio (manchmal entwickeln wir auch in C# ;))  auf das System kam und in dem Ordner noch nicht anständig wollte. nachdem wir das soweit hatten und auch alles sauber loslief, haben wir ins passende Plugin-Verzeichnis unser neues „Plugin“ kopiert und dann einen Ordner Tests angelegt.

PHPUnit-Tests – jetzt aber!?

Um erst mal warm zu werden haben wir erst mal ganz einfache Tests geschrieben. Wir wollten zunächst nur prüfen, ob unser Plugin aktiviert wurde, einen Menüeintrag im Adminmenu erzeugt und die Adminseite im Ansatz beim Aufruf der URL irgendwas an Inhalt erzeugt. Da kam aber schon die erste Frage in uns auf: Wie aktiviert man denn ein Plugin, wenn man gerade nicht die WordPress-typische Pluginseite vor der Nase hat? Etwas knifflig. Wir befragten also wieder das Internet und dort hieß es: Einfach in der Datenbank in den Optionen das Plugin unter den aktivierten Plugins mit eintragen. Ok – also auf die lokale DB mittels phpMyAdmin gegangen und: Die Datenbank ist ja leer? Moment – wir hatten doch vorhin mittels npm und grunt das ganze „installaliert“? Offenbar gereicht diese „Installation“ aber nicht soweit, dass auch eine DB ordentlich angelegt wird. Das Internet riet dazu, aus einer anderen frischen WordPress-Installation einfach die WordPress-eigenen Tabellen zu importieren. Gut also auch das erledigt.

Jetzt aber zu den Tests? Noch nicht ganz. Unser geschriebener Test hatte als erstes Problem das die Ausgabe bereits erzeugt wurde, bevor das PHPUnit-Testgebilde seine Ausgabe gestartet hat. Ein klassisches Problem von Output vor den Headern. Aber auch sonst gab es haufenweise Probleme. Es genügte nicht die wp-load.php einzubinden und ggf. noch die wp-config. Es musste tatsächlich für alle benötigten Funktionen jeweils die passende wp-* Datei eingebunden werden in die Testklasse.

Erstes Fazit

Naja so ganz zufrieden sind wir mit den Bedingungen noch nicht. Eigentlich war nicht der Plan, alle Dateien „manuell“ einzubinden nur um dann einen Test fahren zu können. Der Plan war, eine Art WordPress-Instanz zu haben, in der man dann vielleicht noch mittels einfacher Hooks oder ähnlichem die benötigten Seiten und Eigenschaften aufrufen kann. Das hat bisher noch nicht geklappt. Aber vielleicht finden wir auch dafür demnächst nochmal eine etwas charmantere Konfiguration. Wir lernen ja noch… Und ach ja: Die Tests sind am Ende erfolgreich verlaufen. 😉