Kontrollieren Sie Ihren Legacy-Refactor mit PEST-Architektur-Tests

PEST entstand 2021 in der Fantasie von Nuno Maduro und Luke Dowling mit dem Ziel, den JEST-ähnlichen Teststil aus der JavaScript-Welt mit Laravel in die PHP-Welt zu bringen. Seitdem gab es zwei große Veröffentlichungen des Projekts und viele neue Funktionen, die für Aufsehen sorgten.

Für mich war es die Einführung von Architektur Prüfung die ich vorher noch nicht gesehen hatte. Sicher, man sollte für alles, was man tut, Tests schreiben (und das sollte man auch!), aber was nützt es, Tests über die tatsächliche Struktur der Anwendung selbst zu schreiben? Nun, wenn man ein Projekt auf der grünen Wiese beginnt: wahrscheinlich nicht sehr viel. Aber hier kommt das Schöne an der Sache ins Spiel: Wie wäre es, wenn man sie in ein großes altes Spaghetti-Legacy-Projekt einführt, das ein kontrolliertes Refactoring benötigt? Jetzt wird's interessant! In diesem Artikel sehen wir uns die einfachsten Ansatzpunkte an, um ein Legacy-Refactoring mit PEST Architecture Testing einzuleiten.

Einer für die technischen Leiter

Was kann es alles? Nun, durch die Verwendung der arch() Zugriffsfunktion können wir mehrere Dinge mit der PEST Expectation API tun:

• Definieren, wo Klassen erweitert werden können und wo nicht

• Legen Sie fest, wo Ihre Schnittstellen liegen

• Definieren, welche Klassen Traits verwenden sollten und welche nicht

• Refaktorieren Sie die zufällige sterben() oder dump() Aufrufe zur Fehlersuche, bevor etwas wie PHPStan/Psalm ausgelöst wird

• Halten Sie Ihre Anwendung an die Namenskonventionen von Laravel

Das sind viele Dinge, die man sofort erledigen kann. Nehmen wir an, Sie erben ein neues Projekt, und in einer Stunde können Sie mit dem Refactoring und High-Level-Tests beginnen. Das ideale Szenario, das Sie sich wünschen, wenn Sie eine Legacy-Codebasis übernehmen, wäre also Folgendes:

• Erstellung eines Styleguides, wie die Logik der neuen Anwendung aussehen und funktionieren soll

• Beginnen Sie mit dem Schreiben fehlerhafter PEST-Tests, um dies umzusetzen.

In gewisser Weise ist das, was hier vorgeschlagen wird, eine Neuimplementierung der verhaltensgesteuerten Entwicklung. Stellen Sie sich den Styleguide als Ihre Gherkin-ähnlichen Tests vor, die Sie dann in PEST in Unit- und Integrationstests übersetzen.

Mit gutem Beispiel vorangehen

All dies ist ohne Beispiele akademisch. Nehmen wir also an, dass Sie eine veraltete Laravel-Codebasis haben. Bevor die Tests ins Spiel kommen, werden Sie entweder ein Auto-Refactoring-Tool wie RectorPHP verwenden wollen, um PHP-Regelsätze festzulegen, die den Code wieder an moderne Konventionen anpassen, oder Sie können Laravel Shift verwenden. Von hier aus können wir PEST mit Composer einführen:

composer require pestphp/pest --dev --with-all-dependencies

Und Sie können dann eine neue PEST-Konfiguration initialisieren:

./vendor/bin/pest --init

Dadurch wird Ihre Pest.php Konfigurationsdatei, die, falls Sie mit der Verwendung von PHPUnit vertraut sind, das Äquivalent zur Konfigurationsdatei phpunit.xml ist. Es ist Zeit, mit der Arbeit zu beginnen.

Was nun?

Does Your Code Look Like This?Hier ist er. Der Grund, warum Sie eine Karriere in der Technik haben. Sie leben dafür, dass Sie eine 15 Jahre alte Laravel-Anwendung geerbt haben, die Debugging-Routen hat, die Kern-CLI-Befehle vollständig offenlegen, Sie haben zirkuläre Abhängigkeiten, und Sie haben wahrscheinlich DB::raw('SELECT * FROM nightmare WHERE refactoring = 1'); überall zu finden.

Wir sollten eine Regel aufstellen, die besagt, dass alle Debugging-Befehle, die versehentlich in die Codebasis übertragen werden, verschwinden müssen, bevor Fortschritte gemacht werden können. Das ist doch das absolute Minimum, oder? Dies ist in PEST integriert. Erstellen Sie also zunächst einen Test in der Befehlszeile über die Konsole:

php artisan pest:test DebbugingRulesetTest

Führen Sie den Testrunner aus:

php artisan test

Sie werden feststellen, dass der Test fehlschlägt, da PEST versucht hat, den Code zu kodieren. Navigieren Sie zu der Testdatei DebuggingRulesetTest.php und ersetzen Sie den Code wie folgt:

<?php

arch()->preset()->php();

Führen Sie die Tests durch, und da Sie ein theoretisches Chaos geerbt haben: Ich erwarte, dass PEST anfängt, an Ihnen herumzunörgeln.

Whoops, No Debugging Code Here, Please!

Alt:

Wir haben die erste Refactor-Regel gesichert, jetzt müssen wir sie durchsetzen. Es gibt mehrere Möglichkeiten, dies zu tun; in Produktionsumgebungen ist es üblich, dass ein Continuous-Integration-Runner wie Bitbucket Pipelines von Atlassian, CI/CD von Gitlab oder Actions von GitHub Regeln auslöst, um Pull Requests zusammenzuführen. Wir werden jedoch die strengsten Regeln implementieren, bei denen Sie können nicht einmal eine Übergabe an den Code vornehmen, ohne dass PEST erfüllt ist.

Dies geschieht über Git-Hooks. Erstellen Sie mit diesem Befehl einen neuen Pre-Commit-Hook:

cd my-code/.git/hooks

// Windows Users Only
echo. > pre-commit

// Unix-like Users Only
touch pre-commit
chmod +x pre-commit

Öffnen Sie die vor der Übergabe Datei, die im vorherigen Schritt erstellt wurde, in einem Texteditor oder einer IDE und fügen Sie den Code zur Ausführung von PEST hinzu:

#!/bin/sh

echo "Pre Commit Test Runner Fired"

# Detect OS

if [ "$(uname 2>/dev/null)" = "Linux" ] || [ "$(uname 2>/dev/null)" = "Darwin" ]; then u
    echo "Running Unix-like"
    CMD="./vendor/bin/pest"
else
    echo "Running Windows"
    CMD="vendor\\bin\\pest.bat"
fi

$CMD
RESULT=$?

if [ $RESULT -ne 0 ]; then
    echo "Cannot Commit, Tests Failed"
    exit 1
fi

echo "Commit Success"

exit 0

Die pre-commit Datei ist ein reservierter Dateiname, den Git für verschiedene Aktionen verwendet - in diesem Fall wird der Inhalt dieser Datei jedes Mal ausgeführt, wenn ein Benutzer versucht, eine Übergabe an die Codebasis vorzunehmen.

Versuchen Sie ruhig, eine Änderung am Code vorzunehmen, und beobachten Sie, was passiert!

Damit sind wir gut gerüstet, um mit dem Refactoring zu beginnen. Die Einrichtung ist abgeschlossen, jetzt geht es nur noch darum, die API-Methoden der PEST-Architekturprüfung zu nutzen. In unserem Test können wir ein paar weitere Regeln auf hoher Ebene hinzufügen:

<?php

arch()->preset()->php(); // our previous rules
arch()->preset()->security();
arch()->preset()->strict();

Ich habe hier ein paar Regeln hinzugefügt, die Sie im Detail im PEST-Quellcode sehen können. Die erste, security(), wird Ihnen bei Ihrem ersten Refactor sehr helfen: Sie sorgt dafür, dass Ihr Code durchfällt und erkennt, wo es ernsthafte Sicherheitslücken gibt. Dazu gehört die Verwendung von Methoden der PHP-Standardbibliothek, die aus Sicherheitsgründen überflüssig geworden sind, wie z.B.

• md5(): MD5-ähnliche Verwendungen müssen wirklich durch SHA256 ersetzt werden. Wenn Sie also Daten wie Sitzungs-IDs oder eindeutige Datenbankbezeichner haben, müssen diese einen ETL-ähnlichen Refactor erhalten

• rand(): Die ursprüngliche Zufallsfunktion von PHP ist nicht wirklich zufällig

• shell_exec(): Das Aufrufen der Shell des Host-Rechners ist möglicherweise das Schlimmste, was Sie tun können. Natürlich werden Sie dies irgendwann tun müssen, aber die Idee ist, dass Sie Laravels Konsole und Wrapped-Methoden für die Sicherheit verwenden, anstatt Legacy-Code Ihren Server in Stücke reißen zu lassen

In Anbetracht der Anzahl der Regeln, die allein in diesen Startpunkten enthalten sind, ist das ein Refactoring im Wert von ein paar Sprints, denke ich! Ich denke, dass man damit alles Mögliche machen kann, da PEST eine ganze Reihe von Tests in der Expectation API ermöglicht.

Schlussfolgerung

Zusammen mit dem Architekturtest wurde in PEST 3 auch der Mutationstest eingeführt, aber das ist ein anderes Mal. Die Menge an Funktionen, mit denen PEST ausgeliefert wird, ist jedoch wirklich ein komplettes Arsenal an Werkzeugen für diejenigen, die Legacy-Projekte übernehmen. Wir bei Vonage haben eine Leidenschaft für das Testen. Haben Sie Lust, mit uns über PHP zu sprechen? Treten Sie unserer florierenden Entwickler-Community auf Slackoder folgen Sie uns auf X (früher Twitter), oder abonnieren Sie unseren Entwickler-Newsletter. Bleiben Sie mit uns in Verbindung, teilen Sie Ihre Fortschritte mit uns und bleiben Sie auf dem Laufenden über Neuigkeiten, Tipps und Veranstaltungen für Entwickler!