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

22

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.

MikeSchinkel
quelle
Ich gehe davon aus, dass Sie über das Testen Ihres eigenen Codes (Themes / Plugins) sprechen. Wenn Sie neuen Code erstellen oder wenn Sie "die Umgebung" aktualisieren (WP, andere Plugins)? Oder beides? Ich denke, dass Pro-Webmaster auch gute Ratschläge zum Testen von Web-Apps (Selen und so weiter) enthalten könnten - vielleicht ist ein Cross-Posting eine gute Idee?
Jan Fabry
@ Jan Fabry - Ja, ich teste meinen eigenen Code. Gute Idee zum Crossposting, das mache ich gleich.
MikeSchinkel

Antworten:

10

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... :-)

Denis
quelle
2
Schöne Antwort, vielen Dank für alle Details, die Sie behandeln. FWIW Ich suche mehr nach "Regressionstests" als nach "Einheitentests" . Ich weiß, dass es viele Überschneidungen gibt, aber mein größtes Problem ist derzeit, zu überprüfen, dass die Website nicht kaputt geht. Ja, das Testen eines Plugins kann die meisten Probleme beheben, aber es ist sehr viel zeit- und arbeitsaufwändiger, eine vollständige Abdeckung für Unit-Tests zu erhalten (was bedeutet, dass ich wahrscheinlich keine vollständige Abdeckung bekomme), wohingegen das Testen einer vollständigen Seite in Bezug auf die Anforderungen viel weniger feinkörnig ist.
MikeSchinkel
1
Beachten Sie, dass es in bestimmten Frameworks (Symfony2 und Li3, um nur zwei zu nennen) Tools gibt, mit denen Sie eine tatsächliche Site mit einem fiktiven Browser testen können. Die betreffenden Komponenten können für andere Zwecke wiederverwendet werden. Auf diese Weise können Sie die Administrationsbildschirme Ihrer Site tatsächlich manipulieren und überprüfen, ob die von Ihnen ausgeführten Aktionen die erwarteten Ergebnisse liefern.
Denis de Bernardy
7

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.

Ethan Seifert
quelle
Vielen Dank für den Vorschlag, ich würde schon früher davon hören. Haben Sie tatsächlich für WordPress-Projekte verwendet? Nur neugierig.
MikeSchinkel
Ja. Ich habe es zum Testen eines Plugins verwendet, an dem ich arbeite. In einem früheren Leben haben wir damit EDC-Apps für die klinische Forschung getestet.
Ethan Seifert
1

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:

JD
quelle
1
Selen und Codeception sind nicht exklusiv. Sie können den WP-Browser verwenden, um Selenium [das einen aktuellen Browser wie Chrome steuert], Phantom [das ein Nicht-GUI-Browser mit JS-Unterstützung ist] oder sogar den PHPBrowser, der ein dummer Curl-Browser ist [sehr schnell, aber kein JS]. dh API-Tests]. WP-Browser kann jeden von ihnen ansteuern.
Jim Maguire