Unit-Tests mit PHPUnit schreiben, Teil 1: Die Einrichtung

Last updated 26. November 2022

Inhalt

Unit-Tests mit PHPUnit, Teil 1: Die Einrichtung

Anfang dieses Monats haben wir uns mit der Installation von PHPUnit in Visual Studio Code beschäftigt, mit dem ultimativen Ziel, zu lernen, wie man Unit-Tests für unsere WordPress-basierten Projekte schreibt.

Zu diesem Zweck geht dieser Beitrag davon aus, dass Sie die folgenden Beiträge gelesen haben, und es wird davon ausgegangen, dass Sie eine Handvoll früherer Beiträge nachgeholt haben:

Und natürlich die Installation von PHPUnit in Visual Studio Code wie oben verlinkt. Sobald dies erledigt ist, können wir fortfahren. Beachten Sie jedoch, dass dies ein traditioneller oder ein umfassender Kurs zum Schreiben von Unit-Tests sein wird.

Stattdessen geht es darum, Unit-Tests für WordPress-Projekte zu schreiben.

Unit-Tests mit PHPUnit, Teil 1: Die Einrichtung

Bevor ich zu tief darauf eingehe, möchte ich klarstellen, dass dies nicht so sehr ein Beitrag zur testgetriebenen Entwicklung ist, sondern ein Beitrag, der die Grundlage für das Verständnis des Schreibens von Unit-Tests legt. Und dann arbeiten wir letztendlich daran, Unit-Tests für unseren Code zu schreiben.

Für diejenigen unter Ihnen, die sich zuvor mit Unit-Tests beschäftigt haben, wissen Sie, dass das Schreiben von Unit-Tests ein Thema ist, zu dem es viele Informationen gibt, und dieser Beitrag wird nicht versuchen, all dies abzudecken. Stattdessen wird ein pragmatischerer Ansatz zum Schreiben von Komponententests für WordPress-basierte Plugins, Webanwendungen und dergleichen verfolgt.

1 Unit-Tests schreiben

Wann immer Sie zum ersten Mal Unit-Tests schreiben, werden Sie sowohl mit der Idee der setUp- als auch mit der tearDown- Methode konfrontiert. Dies ist in PHPUnit üblich (wie bei anderen Testframeworks). Es gibt ein paar Dinge bei diesen beiden speziellen Methoden, die oft Probleme verursachen.

Kurz gesagt behandeln die Leute die Funktionen wie folgt:

setUp ist wie der Konstruktor, in dem Sie Ihre Klasse instanziieren und dann alles vorbereiten, was Sie für Ihren Test benötigen, einschließlich des zu testenden Objekts, der erforderlichen Daten und so weiter.
tearDown ist der Destruktor, bei dem Sie alles zurücksetzen und dann Ihre Objekte entsorgen. Dies ist normalerweise häufiger in kompilierten Sprachen, aber auch innerhalb von PHPUnit nicht zu übersehen.

Und obwohl ich das vollkommen verstehen kann, ist es nicht immer der Fall. Auch hier spreche ich aus Erfahrung. Stattdessen kommt hier der eigentliche Ausdruck Unit Testing. Es dreht sich alles um das Testen von Unit-Code-Code, und zwar auf saubere, prägnante Weise.

Wofür sind diese Methoden überhaupt? Dies kann eine besonders schwierige Angewohnheit oder sogar ein konzeptionelles Modell sein, das zu brechen ist, wenn Sie zum ersten Mal in den Prozess einsteigen. Zu diesem Zweck möchte ich den Zweck jeder Methode untersuchen und dann, wie man dies bei der Arbeit mit WordPress-basierten Projekten angeht.

Und wie üblich werde ich darauf abzielen, dies so einfach und pragmatisch wie möglich zu halten. Ich interessiere mich weit weniger für die Theorie hinter bestimmten Dingen als dafür, wie sie sowohl meinem Geschäft als auch meinen Projekten gut dienen kann. (Dies soll natürlich nicht die Theorie abtun, aber es gibt eine Zeit, in der das nicht der richtige Ort ist, und dieser Blog ist es nicht.)

2 Die setUp-Funktion

Auch wenn ich mit einer kurzen Erläuterung der setUp -Methode beginne, ist es wichtig, im Hinterkopf zu behalten, dass ihre Schwesterfunktion (wie manche meinen) nicht immer benötigt wird.

Wenn Sie beispielsweise Code schreiben, bei dem Sie lediglich ein Objekt oder eine Gruppe von Objekten instanziieren, wird die TearDown- Methode möglicherweise nicht benötigt. Darauf werde ich im nächsten Abschnitt näher eingehen.

Nehmen wir an, Sie haben eine Klasse, die für die Ausführung eines Teils der Domänenlogik verantwortlich ist. Denken Sie daran, dass wir uns für die Zwecke dieses Beitrags nicht mit Code befassen, der Dinge tut, die WordPress von Natur aus tut und der bereits seine eigenen Tests hat.

Damit meine ich, dass wir uns mit Code befassen, der speziell in einer Problemdomäne funktioniert. Vielleicht geht es uns zum Beispiel darum, eine Klasse zu schreiben, die Daten in der Datenbank zwischenspeichert. Eine der Informationen, die für das Zwischenspeichern von Informationen verantwortlich sind, ist, wie lange die Daten zwischengespeichert werden sollen. Ein Kandidat für den Unit-Test würde also davon ausgehen, dass wir die Zeitdauer festlegen und ändern können, richtig?

Zugegeben, vielleicht sind diese Daten fest codiert, aber nehmen wir zu Beispielszwecken etwas anderes an. Dies impliziert Folgendes:

Wir haben eine Klasse, die als unser Cache dient,
Die Klasse verwaltet von einem Stück Instanzdaten, wie lange der Cache gesetzt werden soll,
Die Cache-Zeit kann von Drittanbieter-Klassen eingestellt werden,
Die Cache-Zeit kann aus Klassen von Drittanbietern gelesen werden.

Das bedeutet, dass ein Unit-Test Folgendes beinhalten würde:

Klasse einrichten,
Wert definieren,
Bestätigen, dass der definierte Wert wie erwartet ist,
Ändern des Wertes,
Das Assertieren des geänderten Werts wurde aktualisiert.

Die Basisklasse könnte also etwa so aussehen ( die gesamte Dokumentation wird aus der Klasse herausgelassen, um den Code so knapp wie möglich zu halten):

<?php

class AcmeCache
{
    private $duration;

    public function __construct()
    {
        $this->duration = 43200;
    }

    public function setDuration($duration)
    {
        $this->duration = $duration;
    }

    public function getDuration()
    {
        return $this->duration;
    }

    // More cache code omitted...
}

Beachten Sie, dass die Cache-Zeit standardmäßig auf 12 Stunden (in Sekunden) eingestellt ist. Die Klasse unterstützt auch die Möglichkeit, die Dauer zu ändern und zu lesen.

Das bedeutet, dass wir Tests schreiben können, die Folgendes testen:

wenn der Anfangswert den Erwartungen entspricht,
ob der neue Wert den Erwartungen entspricht (und den ursprünglichen Wert überschreibt)

<?php

use PHPUnitFrameworkTestCase;

class AcmeCacheTest extends TestCase
{
  protected $cache;

  protected function setUp()
  {
    $this->cache = new AcmeCache();
  }

  public function testDefaultDuration()
  {
    $this->assertTrue($this->cache->getDuration() === 43200);
  }

  public function testNewDuration()
  {
    $this->cache->setDuration(1000);

    $this->assertFalse($this->cache->getDuration() === 43200);
    $this->assertTrue($this->cache->getDuration() === 1000);
  }

  // More to come...
}

Eines der Dinge, die ich im obigen Code hervorheben möchte, ist, dass Sie lesen können, dass jeder Test eine einzelne Assertion haben sollte, während by testNewDuration eindeutig zwei Assertionen hat.

Ich neige dazu, die Idee von einer Aussage pro Test als Faustregel zu nehmen. In diesem Fall möchte ich beispielsweise behaupten, dass der Anfangswert überschrieben oder nirgendwo gespeichert und der neue Wert gespeichert wird.

Dies ist jedoch möglicherweise nicht immer der Fall, daher müssen Sie diese Art von Situationen möglicherweise mit Sorgfalt behandeln.

Wie Sie sehen können, hat dies nichts mit WordPress zu tun; es hat jedoch mit Testlogik zu tun, die sich speziell auf die jeweilige Domäne bezieht. Nämlich die Dauer des Caches. Und genau darum geht es beim Unit-Testen: Das logische Verhalten von Codeeinheiten testen, um sicherzustellen, dass die Dinge wie erwartet funktionieren.

Und je nachdem, wann Sie diesen Code schreiben, haben Sie möglicherweise fehlgeschlagene Tests. Dies kann letztendlich beim Klassendesign helfen, aber das ist ein anderes Thema und nicht Teil dieses Beitrags.

Ausführen der Tests

Sobald die Tests geschrieben sind, ist es wichtig, sie ausführen zu können, um zu sehen, ob sie bestehen, ob sie fehlschlagen, was bestanden wird und was nicht. Aber wir sind noch nicht fertig. Ich möchte einen umfassenden Blick auf Unit-Tests im Kontext von WordPress werfen und dabei diskutieren, was WordPress bietet, was nicht, einige Missverständnisse und wie diese Tests im Terminal oder in Visual Studio Code ausgeführt werden.

Im nächsten Beitrag dieser Serie werden wir uns die TearDown- Funktion ansehen und wie (und wann) sie verwendet wird, wann sie benötigt wird, wann nicht, und dann werden wir uns ein wenig mit der Einheit befassen Testen in WordPress im Allgemeinen.

Letztendlich arbeiten wir daran, uns ein vollständiges Bild davon zu machen, wie man das macht und wie man es richtig macht. Aber es ist wichtig, den Grundstein dafür zu legen, und das über ein paar Posts zu tun, ist einfacher als in einem monolithischen Post.

Die Untersuchung von tearDown(), seiner Verwendung und der Ausführung von Tests über die Befehlszeile wird das Thema des nächsten Beitrags in dieser Serie sein.

Aufnahmequelle: tommcfarlin.com