Akzeptanztests für WordPress Plugins

Wie manche von Euch wissen, helfe ich ab und an im Pluginkollektiv aus. Dort kümmere mich derzeit vor allem um das Plugin Antispam Bee. Da es sich dabei um ein relativ bekanntes und großes Plugin handelt und Bugs entsprechende Wellen ziehen, stellte sich mir die Frage wie wir in stabilere Releases kommen.

Alain Schlesser hatte schon vor einiger Zeit einige Unittests für das Plugin geschrieben. Doch die derzeitige Architektur verhindert leider eine bessere Abdeckung mit sogenannten Unittests. Ich hatte mich deshalb dafür entschieden, ein ganzes Bündel an Akzeptanztests zu schreiben um sicherzustellen, dass ein neues Release nicht aus Versehen bestimmte Features des Plugins zerstört.

Im Dezember letzten Jahres fand das WordCamp Thessaloniki statt. Mit der Unterstützung meines Arbeitgebers Inpsyde, für den ich schon zuvor einen Beitrag zu diesem Thema verfasst hatte, konnte ich mich bewerben und einen Talk vorbereiten, welcher näher darlegt, wie man mit Hilfe von Behat und Wordhat seine eigenen Plugins oder WordPress Installationen automatischen Akzeptanztests unterziehen kann. Dieser Talk ist nun auf WordPress.tv veröffentlicht worden:

Was sind Akzeptanztests?

Der Talk selbst ist ziemlich technisch. Doch, um was geht es eigentlich? Stellen wir uns folgende Kundenanforderung vor: Eure Kundin hat eine Webseite und möchte dort nun ein bestimmtes Feature realisieren.

Ich möchte auf der rechten Seite meines Blogs eine Box haben, mit einem Bild meines Produktes X und dem Text „Weitere Informationen zu X“. Der Text soll verlinkt sein und wenn ein Besucher auf diesen Link klickt, so soll er auf die Seite „Über X“ kommen.

Eine relativ simple Anforderung also, welche man mit Hilfe eines kleinen Widgets in der Sidebar schnell erledigen kann. Nachdem Ihr also alles vorbereitet habt kommt Ihr zu Eurer Kundin zurück und sagt, das alles soweit vorbereitet ist. Die Kundin wird nun die Webseite aufmachen, gucken, ob sie auf der rechten Seite besagtes Feature findet und ob, wenn sie auf den Link klickt an der richtigen Stelle herauskommt.

Sie testet also, ob die Kriterien erfüllt sind, unter welchen Sie das neue Feature akzeptieren würde: Sie führt einen Akzeptanztest aus. Solche Tests wollen wir nun automatisieren. Wenn wir eine Webseite oder ein Plugin weiter entwickeln können wir so sichergehen, dass unsere Weiterentwicklungen die bisherigen Akzeptanzkriterien nicht aus Versehen wieder brechen.

Akzeptanzkritieren formalisieren

Als einen ersten Schritt müssen wir dazu diese Kritieren in eine formalisierte Sprache übersetzen. Das Framework, auf welchem wir aufbauen, um unsere Tests zu automatisieren, heißt Behat. Für die Formalisierung der Tests bringt Behat die Sprache Gherkin mit. Das schöne an dieser Sprache ist, dass man nicht unbedingt PHP oder eine andere Programmiersprache beherrschen muss, um einen solchen Test zu schreiben:

Given I am on "/"
When I click on "Weitere Informationen zu X"
Then I should see "Über X"

Dieser Dreizeiler würde sicherstellen, dass es auf der Startseite einen Link mit dem Text „Weitere Informationen über X“ gibt und wenn man auf diesen klickt sollte man „Über X“ sehen, sich also auf der Seite befinden, auf der „Über X“ steht.

Ein konkretes Beispiel aus Antispam Bee

In Antispam Bee gibt es das Spracherkennungsfeature. Man kann festlegen, dass nur Kommentare, welche in einer bestimmten Sprache verfasst sind angenommen werden und alle anderen als Spam markiert werden:

Für dieses Feature hatten wir bisher immer die Google Translate API genutzt. War das Feature aktiviert schickten wir also den Text zu dieser API und diese gab uns die Sprache zurück. Das zentrale Problem mit der Translate API von Google war allerdings: Sie kostete Geld. Je beliebter Antispam Bee wurde, desto tiefer griff Simon, der sich bereit erklärt hatte die Kosten zu übernehmen, in seine privaten Taschen.

Mit franc hingegen stand eine kostenlose Alternative zur Verfügung, welche wir nur einzubauen brauchten. In Version 2.9.0 wechselten wir also im Hintergrund die APIs aus und Antispam Bee lief seither mit franc.

Dann erhielten wir Berichte, dass einige Kommentare zurückgewiesen wurden, welche zwar in Deutsch aber nicht in Hochdeutsch verfasst wurden. Wir prüften also, welchen Wert franc bei dem betroffenen Test zurück gab und stellten fest, dass franc diesen als Niederdeutsch erkannte. Wir beschlossen also, dass wir Niederdeutsche Texte als deutsche Texte durchgehen lassen wollten. Dieses neue Feature implementierten wir in 2.9.1 und gleichzeitig fügten wir auch einen neuen Akzeptanztest hinzu:

  Scenario: Comment Language
    Given the option "translate_api,flag_spam" is set
    Given the option "translate_lang" has the array value "de"
    Given I am on "/?p=1"
    Then I fill in "comment" with "Well over d' Hund kummt, de kummt ok over d' Steert"
    Then I fill in "author" with "Monty"
    Then I fill in "email" with "monty.1983@nuclear-secrets.com"
    Then I fill in "url" with "http://nuclear-secrets.com"
    Then I press "submit"
    Then I should not see "Fatal"
    Then I should see "Hello world"
    Then I should not see "Notice"

    Given I am logged in as admin
    Given I am on "/wp-admin/edit-comments.php?comment_status=spam"
    Then I should not see "Monty"
    Then I should not see "Comment Language"
    Given I am on "/wp-admin/edit-comments.php"
    Then I should see "Monty"

Nehmen wir nun an, in Zukunft wollten wir erneut die Spracherkennungs-API wechseln. Würden wir dies tun und wir kämen dabei in Probleme mit der korrekten Erkennung niederdeutscher Texte könnten wir diese nun schon vor dem Release beheben.

Automatisieren wir das nun

Die Entwicklung von Antispam Bee findet auf GitHub statt. Zusammen mit TravisCI bietet GitHub Open Source Projekten wie unserem einen kostenlosen Service an. Im Wesentlichen können wir die Server von Travis benutzen, um auf diesen automatisierte Tests durchzuführen. Wir können die Testsuite, welche wir geschrieben haben, auf den Servern von Travis ausführen.

Und dies tun wir. Wir haben eine kleine Datei, die .travis.yml, in unserem Repository, welche die Anweisungen an Travis enthält, was zu tun ist. Jedes Mal, wenn jemand einen Pull Request eröffnet oder auch nur einen Commit vornimmt werden unsere Akzeptanztests durchgeführt. Das Ergebnis dieser Tests liefert Travis nun zurück an GitHub. GitHub kann uns so schnell anzeigen ob eine Codeänderung zu Probleme führt:

Klicken wir auf die „Details“ kommen wir zur Testauswertung und können so schnell erkennen, welches Feature kaputt gehen würde. Dies hilft natürlich enorm bei der Fehlerbehebung.

Das schöne an dieser Automatisierung ist, dass wir diese nun schnell an verschiedene Bedingungen anpassen können:

Statt einfach nur die aktuellste WordPress Version zu testen können wir mit Hilfe des Testscripts (vielen Dank auch an Christian, sein Script hier diente quasi also Vorlage) unser Plugin automatisiert unter verschiedenen WordPress Versionen testen und auch unter der WordPress Version, welche gerade erst entwickelt wird und noch gar nicht veröffentlicht ist! Mögliche Probleme mit einer zukünftigen Version können wir so ziemlich frühzeitig entdecken und könnten entsprechend gegensteuern.

Wenn Ihr Euch mehr für die Details interessiert, hoffe ich mein Vortrag auf dem Wordcamp Thessaloniki hilft Euch weiter. Im Wesentlichen nutzen wir

• Behat
• Mink
• Selenium
• WordHat

um Antispam Bee ständig durchgetestet zu haben und Euch so ein möglichst ruckelfreies Updaten zu gewährleisten. Natürlich kann es immer wieder, trotz der tollsten Testsuite zu Problemen kommen. Beispielsweise zu Pluginkonflikten oder eben zu Dingen, die wir nicht bedacht hatten (wie Niederdeutsch).

Wenn Ihr mal Probleme mit Antispam Bee habt, meldet Euch entsprechend im WordPress Support Forum oder auf GitHub. Das Pluginkollektiv besteht aus zahlreichen Freiwilligen, welche Euch – so schnell es ihnen möglich ist – versuchen zu helfen.

Danke nochmal an Inpsyde, dass Ihr es mir ermöglicht habt nach Thessaloniki zu fliegen und den Talk zu geben. Neben dem Talk konnten wir so einen Übersetzer finden, welcher das Plugin nach Griechisch übersetzte! Vielen Dank auch an die vielen Organisatoren und Freiwilligen, welche das WordCamp zu einer ganz besonderen Erfahrung gemacht haben!