Unit-Tests mit PHPUnit schreiben, Teil 2: Der Teardown

Ende letzten Monats habe ich angefangen, über das Schreiben von Unit-Tests in PHPUnit für WordPress-basierten Code zu sprechen. Dazu gehörte vor allem die Idee, PHPUnit, die setUp- Funktion, einzurichten und grundlegende Tests zu schreiben.

Dabei ging es jedoch nicht um das, was ich über die TearDown- Funktion weiß, die immer noch ein wichtiges Merkmal beim Schreiben mit Tests ist. Darüber hinaus gibt es zwei Möglichkeiten, Tests für WordPress-Projekte zu schreiben.

Nämlich:

1. Schreiben von Tests speziell für Plugins und Funktionen auf Anwendungsebene,
2. Ausführen von Komponententests für die WordPress-Anwendung.

Bevor ich jedoch mit diesem speziellen Beitrag fortfahre, empfehle ich, das nachzuholen, was ich bisher behandelt habe. Dazu gehören folgende Beiträge:

1. Eine WordPress-Entwicklungsumgebung (mit einem Paketmanager)
2. Eine IDE für die WordPress-Entwicklung
3. Arbeiten mit Benutzereinstellungen in Visual Studio Code
4. Unit-Tests mit PHPUnit schreiben, Teil 1: Die Einrichtung

Wenn Sie das getan haben, kehren Sie zu diesem Beitrag zurück und lassen Sie uns weiter über die TearDown-Funktion diskutieren und wie Unit-Tests im Kontext von WordPress tatsächlich aussehen.

Unit-Tests mit PHPUnit, Teil 2: Der Teardown

Bevor Sie fortfahren, denken Sie daran, dass Entwickler die Funktion setUp oft wie den Konstruktor und die Funktion tearDown wie einen Destruktor behandeln; Denken Sie jedoch daran, dass letzteres nicht immer erforderlich ist.

Hier ist eine gute Faustregel, die Sie sich merken sollten:

• Alles, was eine Testfunktion benötigt, ruft die setUp- Funktion auf, sodass die erforderlichen Klassen benötigt werden.
• Die TearDown- Funktion wird nicht immer benötigt, da die setUp- Funktion eine Klasse neu initialisieren kann.

Was bedeutet das also für die TearDown -Funktion, wenn sie keine Daten zurücksetzt, die während der SetUp- Funktion erstellt wurden?

1 Die TearDown-Funktion

Der beste Rat, den ich in Bezug auf die TearDown- Funktion geben kann, ist, dass sie verwendet werden sollte, wenn während eines der Tests etwas eingerichtet wird, das zurückgelassen wird.

Dies kann etwas sein, das in eine Datenbank geschrieben wird, etwas, das in ein Protokoll geschrieben wird, oder etwas, das allgemeiner auf die Festplatte geschrieben wird.

Wenn also ein Test einen Datensatz oder eine Datei schreibt, wird die TearDown- Methode nach einem Test ausgeführt und sollte alle auf dem Laufwerk aufgezeichneten Tests entfernen, die nicht Teil des Tests sind, aber nicht dauerhaft für den nächsten Test oder diesen benötigt werden sollte nach sich selbst aufgeräumt werden.

In gewisser Weise ist es also wie ein Destruktor, aber wenn Sie noch nie eine Sprache verwendet haben, die einen Destruktor hat, erscheint diese Nomenklatur entweder irrelevant oder ergibt keinen Sinn.

Ein Destruktor ist eine spezielle Elementfunktion, die aufgerufen wird, wenn die Lebensdauer eines Objekts endet. Der Zweck des Destruktors besteht darin, die Ressourcen freizugeben, die das Objekt möglicherweise während seiner Lebensdauer erworben hat.

Daher ist es vielleicht besser, sich die Funktion einfach als eine Möglichkeit zum Aufräumen nach einem Test vorzustellen (und nicht im Sinne des Setzens einer Variablen auf null, da die Funktion setUp dies tun kann).

2 Komponententests für WordPress-Projekte

Beim Schreiben von Unit-Tests für WordPress-Projekte müssen wir sicherstellen, dass wir uns darüber im Klaren sind, über welche Art von Unit-Tests wir sprechen.

Was ich zum Beispiel als klassische oder standardmäßige Unit-Tests bezeichne, folgt der Methodik der „testgetriebenen Entwicklung”, auf die ich gleich noch zu sprechen kommen werde. Auf der anderen Seite hat WordPress seinen eigenen Satz von Unit-Tests für Themen und dergleichen, auf die ich später in diesem Beitrag auch noch eingehen werde.

Aber für diesen Abschnitt dachte ich, es könnte hilfreich sein, ein wenig über Ersteres und nicht über Letzteres zu sprechen, damit Sie sehen können, wie dies funktionieren könnte.

Im folgenden Beispiel schreibe ich Tests für ein Plugin, das für die Kommunikation mit einer Drittanbieter-API verantwortlich ist. Dieses spezielle Plugin erfordert einen Benutzernamen und ein Passwort oder eine API, und wir möchten sicherstellen, dass es für die Zwecke dieses Beitrags einen Fehler korrekt abruft, wenn der Test ausgeführt wird.

Beachten Sie, dass Sie beim Lesen dieses Codes sehen werden, wie ich ein wenig über Reflexion spreche. Ich werde bald einen ganzen Beitrag über PHP Reflection schreiben, damit dies etwas Licht ins Dunkel bringt.

Gehen Sie für den folgenden Code jedoch davon aus, dass wir auf diese Weise auf Eigenschaften zugreifen können, die ansonsten als privat gekennzeichnet sind.

Erinnern Sie sich an den letzten Beitrag in dieser Serie, wir hatten einen ersten Test, der so aussah :

Beachten Sie jedoch, dass es in diesem Test keine sinnvolle TearDown- Funktion gibt, oder? Schließlich wird nichts in eine Datenbank oder in eine Datei geschrieben.

Aber nehmen wir an, wir wollen einen Testfall einführen, der einen Dateinamen und Inhalt hat und den Inhalt in die Datei schreibt. In diesem Fall handelt es sich um statische Daten, aber dies könnte technisch gesehen alles sein, was auf die Festplatte geschrieben wird.

1 Einrichten des Tests

Zuerst wollen wir den Test einrichten, indem wir den Dateinamen und den Inhalt der Datei definieren und die Eigenschaften vorbereiten.

Einfach genug, oder?

2 Daten schreiben und lesen

Als nächstes wollen wir die Daten schreiben, die Daten lesen und behaupten, dass die Inhalte gleich sind.

Wenn Sie an diesem Punkt den Test ausführen (was ich noch nicht technisch behandelt habe), werden Sie feststellen, dass sich testFile.txt immer noch auf Ihrem System befindet.

3 Verwendung von TearDown

Schließlich müssen wir mit der TearDown- Methode arbeiten, um sicherzustellen, dass die Datei nach Abschluss des Komponententests gelöscht wird. So könnte es aussehen, wenn Sie Ihren Code so implementiert haben, wie Sie es oben sehen.

Beachten Sie, dass ich in der tearDown- Methode zuerst überprüfe, ob eine file_exists. Dies liegt daran, dass, wenn Sie einfach versuchen, eine nicht vorhandene Datei zu trennen, beim Ausführen Ihrer Tests eine Fehlermeldung angezeigt wird, da TearDown nach jeder einzelnen Testfunktion versuchen wird, etwas zu löschen, wenn TearDown vorhanden ist. Und wenn die Datei nicht existiert, gibt es nichts zu löschen, und daher wird es zu einem Problem kommen.

Bei dem Versuch, Code defensiv zu schreiben, glaube ich, dass er dafür verantwortlich ist, zu prüfen, ob die Datei existiert, bevor er tatsächlich versucht, sie zu löschen.

3 Reihenfolge der Operationen

Wenn es um reine Unit-Tests geht, werden Sie dies normalerweise in Begriffen von testgetriebener Entwicklung lesen. Dies ist ein großes Thema für sich; Es ist hier jedoch erwähnenswert, falls Sie sich dafür entscheiden, es weiter zu erforschen und es sogar in Ihre Entwicklungsbemühungen zu implementieren.

Die allgemeine Idee hinter diesem Ansatz wird oft als „Rot-Grün-Wiederholung” bezeichnet. Und ich leugne es nicht, an diesem Ansatz ist etwas dran. Als Entwickler können Sie nämlich Code so schreiben, wie Sie es erwarten, bevor Sie den Code tatsächlich schreiben.

Die Psychologie dahinter ist folgende: Wenn Sie wissen, wie der Code funktioniert, schreiben Sie mit größerer Wahrscheinlichkeit Tests, die bestehen; Wenn Sie dagegen Tests für die Leistung des Codes schreiben, sollten Sie besseren Code schreiben.

Leider können wir uns diesen Luxus nicht immer leisten. Aber das bedeutet nicht, dass wir das sprichwörtliche Baby mit dem Wasser ausschütten sollten. Stattdessen bin ich der Meinung, dass Sie Tests schreiben sollten, wenn Sie können, und den Code danach schreiben; Andernfalls schreiben Sie Ihre Tests nach Ihrem Code.

Letztendlich ist es besser, unabhängig davon Tests durchzuführen, als gar keine Tests.

4 Testen mit WordPress

Wenn es um Komponententests in WordPress geht, gibt es ein paar Dinge, über die Sie wahrscheinlich gestolpert sind. Manchmal ist der Inhalt eine falsche Bezeichnung oder sogar irreführend in Bezug auf „Einheitentests in WordPress”.

In diesem Fall sind zwei Dinge erwähnenswert:

1. Der Theme-Unit-Test. Dieser spezielle Satz von Inhalten soll Theme-Entwicklern dabei helfen, alle Haupt- und Nebenfälle für ihre Themes zu testen. Es gibt zum Beispiel keine automatisierten Tools, die Sie wie oben besprochen verwenden würden.
2. Automatisiertes Testen. WordPress wird mit einem eigenen Satz von Unit-Tests ausgeliefert, sodass wir keine Tests für die meisten Funktionen in WordPress schreiben müssen (z. B. ob API-Funktionen wie erwartet funktionieren oder nicht). Dadurch können wir uns auf das Schreiben von Komponententests für unsere eigene Domänenlogik konzentrieren.
3. Plugin-Unit-Tests. Wenn Sie WP-CLI verwendet haben (oder daran interessiert sind), dann haben Sie wahrscheinlich diese Seite gelesen oder sogar dieses Tool verwendet. Es ist nützlich, aber es zielt auch auf bestimmte Aspekte des Testens von WordPress-Plugins ab.

All dies sind nützliche Informationen, und ich sage nicht, dass sie ignoriert werden sollten. Stattdessen sollte es mit den restlichen Informationen gekoppelt werden, die in diesem Beitrag verwendet werden.

Unit-Tests ausführen

Im nächsten Beitrag werde ich Sie durch alles führen, was Sie wissen müssen, um eine XML-Datei einzurichten, die PHPUnit darüber informiert, wo sich die Tests befinden und wie sie ausgeführt werden.

Sehen Sie sich jedoch vorerst den Code in diesem Beitrag an und bereiten Sie sich darauf vor, im nächsten Beitrag dieser Reihe darauf aufzubauen.