In der Firma predige ich immer wieder: Macht Unit Tests, wenn ihr Probleme in euren Plugins vermeiden bzw. aufdecken wollt, sorgenfrei dem nächsten Deploy entgegen schauen möchtet und eurem in der Zukunft eintreffenden Teammitgliedern die Eingewöhnung erleichtern wollt. Ich schreibe predigen, weil ich mich häufig wiederholen muss und ich auch immer wieder die klassischen Ausreden höre.
In meinem Team wird immer getestet – sowohl klassisches Unit Testing als auch die Mitarbeit bei der Vorbereitung der Acceptance Tests, die aber schlussendlich im Quality Assurance Team durchgeführt werden (dazu gibt es bestimmt noch mehr in einem weiteren Post). Von den Integrationstests, welche die Infrastruktur von WordPress benutzen, sind wir fast komplett abgekommen. Aber ich würde auch diese Form des Testens nicht ganz als sinnlos abtun, momentan liegt da halt nicht wirklich unser Fokus drauf.
Für das Testen der Units benutzen wir nach wie vor PHPUnit. Allerdings wollen wir unseren Code komplett unabhängig von WordPress und in der Konsequenz auch von der Datenbank testen. Damit die Units wirklich isoliert getestet werden können, müssen die Funktionalitäten von WordPress aber irgendwie verfügbar gemacht werden. Dafür setzen wir Platzhalter und Scheinobjekte ein, wie Stubs und Mocks.
Das klappt mit reinem OOP auch gut, wird bei WordPress aber schnell zur Frustration, da auch eine Reihe der API Funktionen gemockt werden muss, was allein mit PHPUnit nicht zielführend ist. Zum Glück gibt es dafür eine Lösung: WP_Mock. Die Installation ist an sich recht einfach. Wenn ihr der Anleitung, die auf dem Git repository zur Verfügung steht, folgt, solltet ihr in wenigen Minuten startbereit sein.
Der Multisite Language Switcher braucht diese Änderung auch. Schuster tragen halt die schlechtesten Schuhe. Falls ihr daran interessiert seid; die (weitere) Entwicklung kann auf GitHub im Branch dev mitverfolgt werden Neben der guten Nachricht, dass man das alles ganz einfach aufsetzen kann, gibt es halt auch die „schlechte“ Nachricht: man muss die Tests nach wie vor schreiben oder wie in meinem Fall anpassen muss.
Hi Dennis,
ehrlich gesagt hatte ich bei dem Titel irgendwie einen ganzen Aufsatz als Post erwartet 😀 – darüber zu schreiben gibt es ja genug. Aber ich stimme dir in nahezu allem zu. Macht (Unit-)Tests, um Aussagen über die Qualität eurer Software zu erhalten, und schreibt euren Code so, dass er testbar ist, auch wenn ihr selbst ihn nicht testen solltet.
Als gut gemeinter Tipp am Rande: schaue dir anstelle von WP_Mock doch einmal Brain Monkey an. Der gesamte Umfang von WP_Mock wird abgedeckt, aber Brain Monkey ist weitaus umfangreicher und mächtiger, ohne dabei komplex in der Nutzung zu sein. Die Dokumentation ist grandios, die Weiterentwicklung stetig, und der Support sucht seines gleichen. 🙂
Aus zuverlässiger Quelle weiß ich übrigens, dass am kommenden Freitag und Samstag eine umfassende zweiteilige Beitragsserie im Adventskalender von Inpsyde über Unit Testing allgemein, und speziell mit Brain Monkey zu lesen sein wird. 😉
Viele Grüße,
Thorsten
Hi Thorsten,
erst einmal – danke für Deinen Kommentar. Und Du hast natürlich Recht, dass man deutlich mehr zu diesem Thema schreiben kann. Meine 24 für den Dezember vorgesehenen Posts werden vermutlich genau das gemeinsam haben; sie werden nur an der Oberfläche der angesprochenen Themen kratzen.
Der Shift weg von den alten WordPress Unit Tests zu WP_Mock war natürlich schon ein recht umfangreiches Unterfangen. Allerdings war das Ergebnis wirklich erste Klasse.
Brain Monkey hatten wir auch gesehen, aber anfangs als Ersatz für mögliche Unzulänglichkeiten von WP_Mock angesehen. Mit Giuseppe Mazzapica (aus eurem Team) haben wir ja auch schon einige male gesprochen, insofern wissen wir auch, wer und was dahinter steckt. 😉
Danke für den Hinweis auf die kommen Artikel bei euch. Die werde ich mir ganz sicher nicht entgehen lassen.
Viele Grüsse zurück!