Best Practices für das Regressionstesten von WordPress-Websites?

Hallo zusammen,

Ich würde gerne erfahren, welche Kunden, die komplexe Lösungen für Nicht-Blogs mit WordPress als Plattform anbieten, was sie für automatisierte Regressionstests verwenden .

Für diejenigen, die mit dem Begriff "Regressionstests" nicht vertraut sind, definiert Wikipedia ihn als:

Regressionstests sind alle Arten von Softwaretests, mit denen versucht wird, Softwarefehler nach Programmänderungen (z. B. Fehlerbehebungen oder neue Funktionen) durch erneutes Testen des Programms zu ermitteln. Mit Regressionstests soll sichergestellt werden, dass durch eine Änderung, z. B. eine Fehlerbehebung, keine neuen Fehler verursacht wurden.

Weiterführend sagt Wikipedia, dass Folgendes genau das ist, was ich gerade in einem Projekt erlebe:

Die Erfahrung hat gezeigt, dass das Auftauchen neuer und / oder das Wiederauftauchen alter Fehler häufig vorkommt, wenn Software repariert wird. Manchmal tritt ein erneutes Auftreten auf, weil ein Fix durch schlechte Revisionskontrollpraktiken (oder durch einfaches menschliches Versagen bei der Revisionskontrolle) verloren geht. Häufig ist eine Problembehebung insofern "fragil", als sie das Problem in dem engen Fall behebt, in dem sie zum ersten Mal beobachtet wurde, nicht jedoch in allgemeineren Fällen, die über die Lebensdauer der Software auftreten können. Häufig führt die Behebung eines Problems in einem Bereich versehentlich zu einem Softwarefehler in einem anderen Bereich. Schließlich ist es häufig der Fall, dass bei der Neugestaltung eines Features dieselben Fehler gemacht wurden, die bei der ursprünglichen Implementierung des Features gemacht wurden.

Angesichts der globalen Natur von Aktionen und Filtern stelle ich fest, dass die Komplexität zunimmt, wenn ich mehr vom Client angeforderte Funktionen hinzufüge, und es schwierig wird, ein komplexes Plug-in stabil zu machen, insbesondere, wenn WP_Querydie Datenbank häufig aufgerufen und aktualisiert wird .

Meiner Meinung nach besteht die Lösung darin, Regressionstests mit einer Reihe von "Testfällen" einzurichten , die eine "Testsuite" umfassen. Im Prinzip ist es nicht so schwierig, die HTML-Ausgabe von HTTP-GET-Anforderungen zu testen. Es wird jedoch etwas komplizierter, wenn Sie Dinge testen müssen, wenn Sie über die Admin-Konsole angemeldet sind, und / oder um jQuery-Interaktionen zu testen.

Ich richte dies als Community-Wiki ein, in der Hoffnung, dass wir hier Best Practices sammeln können, aber ich bin sehr gespannt darauf, Prozesse zu hören, die von anderen WordPress-Profis verwendet werden.

PHPUnit würde in den Sinn kommen, wenn die WP-Testsuite nicht so kaputt wäre und wenn WP so entworfen und geschrieben worden wäre, dass es tatsächlich richtig getestet werden könnte. ;-)

Im Ernst, Sie können Ihre Plugins mit Unit-Tests und dergleichen auf ihre Funktionalität testen. Das Problem ist, dass diese Tests nicht garantieren, dass sie subtile Chancen durch WP-Upgrades erkennen, geschweige denn, dass sie nach dem Anschließen an eine angepasste WP-Installation weiter funktionieren.

Zu den bunten Dingen, die ich gesehen habe, gehören:

• Eine geringfügige Änderung in der WP-API wirkt sich auf die Funktionalität Ihres Plugins aus, z. B. auf den Hook, mit dem Sie eine Term-ID abrufen, und auf den Hook, mit dem Sie eine Term-Taxonomie-ID abrufen. (Es ist gut möglich, dass Ihre Testbedingungen für beide die gleiche ID haben.)

• Eine geringfügige Änderung in der WP-API führt dazu, dass Sie ein WP_ErrorObjekt anstelle des zuvor erwarteten Werts falseals fehlerhafte Eingabe erhalten.

• Ihr Plugin wird aus dem mu-plugins-Ordner hinzugefügt, was zu einem geringfügig anderen Code-Fluss führt.

• Ihr Plugin hat einwandfrei funktioniert, bis memcached oder ein anderer persistenter Speicher aktiviert wurde.

• Dein Plugin hat gut funktioniert, bis das verachtete switch_to_blog () aufgerufen wurde.

• Ein Plugin ändert den Hook, auf dem es sich befindet, wenn es aufgerufen wird, und unterbricht es unwissentlich als Nebeneffekt.

• Ein Plugin (un?) Spielt wissentlich mit Ihren Eingabe- oder Ausgabedaten herum, bis Dinge kaputt aussehen, auch wenn Sie keine Schuld haben.

Ich könnte die Liste immer weiter erweitern, aber das wären die Schlüsselelemente, die meine eigenen Plugins kaputt gemacht haben. Die beiden Gegenstände sind wohl mit Unit-Tests fangbar. Die nächsten beiden auch, wenn Sie geduldig genug sind, aber ich würde argumentieren, dass WP die Art und Weise, wie Dinge funktionieren, wenn sie auftreten, nicht ändern sollte. Um die fehlerhafte Implementierung von switch_to_blog () wird keine Menge an Tests funktionieren. Und die letzten beiden sind hoffnungslos unprüfbar.

Oh, und ... lassen Sie mich nicht einmal mit dem Ansturm von Anhängen, automatischen Entwürfen, Überarbeitungen, Menüelementen und allem, was nicht in der Beitragstabelle gespeichert ist, beginnen.

Viel Glück... :-)

Sie sollten Selen unbedingt in Betracht ziehen .

Hier können Sie Aktionen aufzeichnen (z. B. Daten in ein Formular eingeben, auf einen Link klicken) und dann Behauptungen erstellen. Es lässt sich auch in PHPUnit integrieren. Ich empfehle die zweiminütige Demo.

Selen ist wahrscheinlich verwendbar, aber ich denke, dass Codeception in der heutigen Zeit besser und einfacher zu handhaben ist. Für die einfachsten visuellen Regressionstests gibt es sogar eine Erweiterung, die Screenshots aufnimmt und diese automatisch für Sie vergleicht.

Natürlich können Codeception WebDriver- Tests noch weiter gehen und funktionale Regressionstests durchführen. Sie können Formulare ausfüllen und senden, auf Schaltflächen und Links auf der Site klicken, JS ausführen usw. Sie können in Ihren Tests einen realen Browser wie Firefox oder Chrome verwenden oder mit PhantomJS kopflose Tests durchführen . Das bedeutet, dass Sie sogar die WebDriver-Tests für Ihr Plugin als Teil des Erstellungsprozesses auf Travis CI ausführen können, wenn Sie möchten.

Es gibt sogar mehrere WordPress-spezifische Bibliotheken, die Ihnen den Einstieg erleichtern:

• WP Browser
• WP Codeception