Erfahren Sie anhand einfacher Beispiele, wie Sie Tests in Laravel mit PHPUnit und PEST durchführen

Wenn es um automatisierte Tests oder Unit-Tests geht, gibt es in jeder Programmiersprache zwei gegensätzliche Meinungen:

• verlorene Zeit
• Ohne geht es nicht

Mit diesem Artikel werden wir versuchen, Ersteres zu überzeugen, insbesondere indem wir zeigen, wie einfach es ist, mit automatisierten Tests in Laravel zu beginnen.

Lassen Sie uns zunächst über das „Warum“ sprechen und dann einige Beispiele für das Wie sehen.

Warum wir automatisierte Tests brauchen

Automatisierte Tests führen Teile des Codes aus und melden etwaige Fehler. So kann man sie am einfachsten beschreiben. Stellen Sie sich vor, Sie führen eine neue Funktion in einer App ein, und dann würde ein persönlicher Roboterassistent die neue Funktion manuell testen und gleichzeitig testen, ob der neue Code keine der alten Funktionen beeinträchtigt.

Das ist der Hauptvorteil: Alle Funktionen werden automatisch erneut getestet. Das mag wie zusätzliche Arbeit erscheinen, aber wenn Sie dem „Roboter“ nicht sagen, dass er es tun soll, sollten wir es alternativ manuell tun, oder? 

Oder es könnten neue Funktionen veröffentlicht werden, ohne zu testen, ob sie funktionieren, in der Hoffnung, dass Benutzer Fehler melden.

Automatisierte Tests können uns mehrere Vorteile bringen:

• Sparen Sie manuelle Testzeit;
• Sie ermöglichen es Ihnen, sowohl bei der Implementierung der neuen als auch bei den konsolidierten Funktionen Zeit zu sparen, indem Sie Regressionen vermeiden.
• Multiplizieren Sie diesen Vorteil mit allen neuen Funktionen und allen bereits implementierten Funktionen.
• Die vorherigen drei Punkte gelten für jede neue Version;
• ...

Stellen Sie sich Ihre Anwendung in ein oder zwei Jahren vor, mit neuen Entwicklern im Team, die den in den Vorjahren geschriebenen Code nicht kennen und nicht einmal wissen, wie man ihn testet. 

Unsere ersten automatisierten Tests

Um den ersten auszuführen automatisiertes Testen in Laravel, Sie müssen keinen Code schreiben. Ja, das hast du richtig gelesen. In der Vorinstallation ist bereits alles konfiguriert und vorbereitetdefiNacht von Laravel, einschließlich des allerersten Basisbeispiels.

Sie können versuchen, ein Laravel-Projekt zu installieren und sofort die ersten Tests durchführen:

laravel new project
cd project
php artisan test

Dies sollte das Ergebnis in Ihrer Konsole sein:

Wenn wir einen Blick auf die Pre werfendefiNacht von Laravel /tests, wir haben zwei Dateien:

tests/Feature/ExampleTest.php:

class ExampleTest extends TestCase
{
    public function test_the_application_returns_a_successful_response()
    {
        $response = $this->get('/');
 
        $response->assertStatus(200);
    }
}

Sie müssen keine Syntax kennen, um zu verstehen, was hier vor sich geht: Laden Sie die Homepage und prüfen Sie, ob der Statuscode angezeigt wird HTTP ist "200 OK".

Wird auch als Methodenname bezeichnet test_the_application_returns_a_successful_response() wird zu lesbarem Text, wenn Sie die Testergebnisse anzeigen, indem Sie einfach das Unterstreichungssymbol durch ein Leerzeichen ersetzen.

tests/Unit/ExampleTest.php :

class ExampleTest extends TestCase
{
    public function test_that_true_is_true()
    {
        $this->assertTrue(true);
    }
}

Scheint ein bisschen sinnlos zu sein, nachzuschauen, ob das wahr ist? 

Wir werden etwas später speziell über Unit-Tests sprechen. Zunächst müssen Sie verstehen, was im Allgemeinen in jedem Test passiert.

• Jede Testdatei im Ordner /tests ist eine PHP-Klasse, die den TestCase von erweitert PHPUnit
• Innerhalb jeder Klasse können Sie mehrere Methoden erstellen, normalerweise eine Methode für eine zu testende Situation
• Innerhalb jeder Methode gibt es drei Aktionen: die Situation vorbereiten, dann Maßnahmen ergreifen und dann überprüfen (bestätigen), ob das Ergebnis den Erwartungen entspricht

Strukturell ist das alles, was Sie wissen müssen, alles andere hängt von den genauen Dingen ab, die Sie testen möchten.

Um eine leere Testklasse zu generieren, führen Sie einfach diesen Befehl aus:

php artisan make:test HomepageTest

Die Datei wird generiert tests/Feature/HomepageTest.php:

class HomepageTest extends TestCase
{
    // Replace this method with your own ones
    public function test_example()
    {
        $response = $this->get('/');
 
        $response->assertStatus(200);
    }
}

Sehen wir uns nun an, was passiert, wenn ein Testcode in Laravel fehlschlägt

Sehen wir uns nun an, was passiert, wenn die Testaussagen nicht das erwartete Ergebnis zurückgeben.

Ändern wir die Beispieltests wie folgt:

class ExampleTest extends TestCase
{
    public function test_the_application_returns_a_successful_response()
    {
        $response = $this->get('/non-existing-url');
 
        $response->assertStatus(200);
    }
}
 
 
class ExampleTest extends TestCase
{
    public function test_that_true_is_false()
    {
        $this->assertTrue(false);
    }
}

Und jetzt, wenn wir den Befehl ausführen php artisan test wieder:

 FAIL  Tests\Unit\ExampleTest
⨯ that true is true
 
 FAIL  Tests\Feature\ExampleTest
⨯ the application returns a successful response
 
---
 
• Tests\Unit\ExampleTest > that true is true
Failed asserting that false is true.
 
at tests/Unit/ExampleTest.php:16
   12▕      * @return void
   13▕      */
   14▕     public function test_that_true_is_true()
   15▕     {
➜  16▕         $this->assertTrue(false);
   17▕     }
   18▕ }
   19▕
 
• Tests\Feature\ExampleTest > the application returns a successful response
Expected response status code [200] but received 404.
Failed asserting that 200 is identical to 404.
 
at tests/Feature/ExampleTest.php:19
   15▕     public function test_the_application_returns_a_successful_response()
   16▕     {
   17▕         $response = $this->get('/non-existing-url');
   18▕
➜  19▕         $response->assertStatus(200);
   20▕     }
   21▕ }
   22▕
 
 
Tests:  2 failed
Time:   0.11s

Es gibt zwei fehlgeschlagene Tests, die als FAIL markiert sind. Nachfolgend finden Sie Erläuterungen und Pfeile, die auf die genaue Zeile der fehlgeschlagenen Tests hinweisen. Fehler werden auf diese Weise angezeigt.

Beispiel: Testen des Registrierungsformularcodes in Laravel

Angenommen, wir haben ein Formular und müssen verschiedene Fälle testen: Wir prüfen, ob es mit ungültigen Daten fehlschlägt, wir prüfen, ob es mit der richtigen Eingabe erfolgreich ist usw.

Das offizielle Starterkit von Laravel Breeze beinhaltet i Testen der darin enthaltenen Funktionalität. Schauen wir uns einige Beispiele von dort an:

tests/Feature/RegistrationTest.php

use App\Providers\RouteServiceProvider;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;
 
class RegistrationTest extends TestCase
{
    use RefreshDatabase;
 
    public function test_registration_screen_can_be_rendered()
    {
        $response = $this->get('/register');
 
        $response->assertStatus(200);
    }
 
    public function test_new_users_can_register()
    {
        $response = $this->post('/register', [
            'name' => 'Test User',
            'email' => 'test@example.com',
            'password' => 'password',
            'password_confirmation' => 'password',
        ]);
 
        $this->assertAuthenticated();
        $response->assertRedirect(RouteServiceProvider::HOME);
    }
}

Hier haben wir zwei Tests in einer Klasse, da sie sich beide auf das Registrierungsformular beziehen: Einer prüft, ob das Formular korrekt geladen wird, und ein anderer prüft, ob die Übermittlung gut funktioniert.

Machen wir uns mit zwei weiteren Methoden zur Überprüfung des Ergebnisses und zwei weiteren Behauptungen vertraut: $this->assertAuthenticated()e $response->assertRedirect(). Sie können alle verfügbaren Behauptungen in der offiziellen Dokumentation von überprüfen PHPUnit e Laravel-Antwort . Beachten Sie, dass es zu diesem Thema einige allgemeine Aussagen gibt $this, während andere das Spezifische prüfen $responseaus dem Routenaufruf.

Eine weitere wichtige Sache ist die use RefreshDatabase;Anweisung, mit dem Strich, eingefügt über der Klasse. Dies ist erforderlich, wenn sich Testaktionen auf die Datenbank auswirken können, da in diesem Beispiel durch die Protokollierung ein neuer Eintrag in der Datenbank hinzugefügt wird usersDatenbanktabelle. Hierzu sollten Sie eine separate Testdatenbank erstellen, die mit aktualisiert wird php artisan migrate:freshjedes Mal, wenn die Tests ausgeführt werden.

Sie haben zwei Möglichkeiten: Erstellen Sie physisch eine separate Datenbank oder verwenden Sie eine In-Memory-SQLite-Datenbank. Beide werden in der Datei konfiguriert phpunit.xmlstandardmäßig bereitgestelltdefiNita mit Laravel. Konkret benötigen Sie diesen Teil:

<php>
    <env name="APP_ENV" value="testing"/>
    <env name="BCRYPT_ROUNDS" value="4"/>
    <env name="CACHE_DRIVER" value="array"/>
    <!-- <env name="DB_CONNECTION" value="sqlite"/> -->
    <!-- <env name="DB_DATABASE" value=":memory:"/> -->
    <env name="MAIL_MAILER" value="array"/>
    <env name="QUEUE_CONNECTION" value="sync"/>
    <env name="SESSION_DRIVER" value="array"/>
    <env name="TELESCOPE_ENABLED" value="false"/>
</php>

Siehe die DB_CONNECTIONe DB_DATABASEWelche werden kommentiert? Wenn Sie SQLite auf Ihrem Server haben, besteht die einfachste Aktion darin, diese Zeilen einfach zu kommentieren, und Ihre Tests werden für diese In-Memory-Datenbank ausgeführt.

Bei diesem Test sagen wir, dass der Benutzer erfolgreich authentifiziert und auf die richtige Homepage weitergeleitet wurde, wir können aber auch die tatsächlichen Daten in der Datenbank testen.

Zusätzlich zu diesem Code:

$this->assertAuthenticated();
$response->assertRedirect(RouteServiceProvider::HOME);

Wir können auch verwenden die Datenbank-Testaussagen und mache so etwas:

$this->assertDatabaseCount('users', 1);
 
// Or...
$this->assertDatabaseHas('users', [
    'email' => 'test@example.com',
]);

Beispiel der Anmeldeseite

Sehen wir uns nun ein weiteres Beispiel einer Anmeldeseite mit Laravel Breeze an

tests/Feature/AuthenticationTest.php:

class AuthenticationTest extends TestCase
{
    use RefreshDatabase;
 
    public function test_login_screen_can_be_rendered()
    {
        $response = $this->get('/login');
 
        $response->assertStatus(200);
    }
 
    public function test_users_can_authenticate_using_the_login_screen()
    {
        $user = User::factory()->create();
 
        $response = $this->post('/login', [
            'email' => $user->email,
            'password' => 'password',
        ]);
 
        $this->assertAuthenticated();
        $response->assertRedirect(RouteServiceProvider::HOME);
    }
 
    public function test_users_can_not_authenticate_with_invalid_password()
    {
        $user = User::factory()->create();
 
        $this->post('/login', [
            'email' => $user->email,
            'password' => 'wrong-password',
        ]);
 
        $this->assertGuest();
    }
}

Es geht um das Anmeldeformular. Die Logik ähnelt der Registrierung, oder? Aber drei Methoden statt zwei, also ist dies ein Beispiel für das Testen sowohl guter als auch schlechter Szenarien. Daher besteht die gemeinsame Logik darin, dass Sie beide Fälle testen sollten: wann die Dinge gut laufen und wann sie scheitern.

Was Sie in diesem Test auch sehen, ist die Verwendung von Datenbankfabriken : Laravel erstellt gefälschten Benutzer ( noch einmal, auf Ihrer aktualisierten Testdatenbank ) und versucht dann, sich mit korrekten oder falschen Anmeldeinformationen anzumelden.

Wieder einmal generiert Laravel die WerksvorabversiondefiNita mit falschen Daten für die UserModell, außerhalb der Box.

database/factories/UserFactory.php:

class UserFactory extends Factory
{
    public function definition()
    {
        return [
            'name' => $this->faker->name(),
            'email' => $this->faker->unique()->safeEmail(),
            'email_verified_at' => now(),
            'password' => '$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi', // password
            'remember_token' => Str::random(10),
        ];
    }
}

Sehen Sie, wie viele Dinge werden von Laravel selbst vorbereitet. Wäre es für uns also einfach, mit dem Testen zu beginnen?

Wenn wir also ausführen php artisan testNach der Installation von Laravel Breeze sollten wir etwa Folgendes sehen:

 PASS  Tests\Unit\ExampleTest
✓ that true is true
 
 PASS  Tests\Feature\Auth\AuthenticationTest
✓ login screen can be rendered
✓ users can authenticate using the login screen
✓ users can not authenticate with invalid password
 
 PASS  Tests\Feature\Auth\EmailVerificationTest
✓ email verification screen can be rendered
✓ email can be verified
✓ email is not verified with invalid hash
 
 PASS  Tests\Feature\Auth\PasswordConfirmationTest
✓ confirm password screen can be rendered
✓ password can be confirmed
✓ password is not confirmed with invalid password
 
 PASS  Tests\Feature\Auth\PasswordResetTest
✓ reset password link screen can be rendered
✓ reset password link can be requested
✓ reset password screen can be rendered
✓ password can be reset with valid token
 
 PASS  Tests\Feature\Auth\RegistrationTest
✓ registration screen can be rendered
✓ new users can register
 
 PASS  Tests\Feature\ExampleTest
✓ the application returns a successful response
 
Tests:  17 passed
Time:   0.61s

Funktionstests im Vergleich mit Unit-Tests und anderen

Sie haben die Unterordner gesehen tests/Feature e tests/Unit ?. 

Was ist der Unterschied zwischen ihnen? 

Weltweit gibt es außerhalb des Laravel/PHP-Ökosystems verschiedene Arten automatisierter Tests. Sie finden Begriffe wie:

• Unit-Tests
• Funktionstests
• Integrationstests
• Funktionstests
• End-to-End-Tests
• Akzeptanztests
• Rauchtests
• usw.

Es klingt kompliziert und die tatsächlichen Unterschiede zwischen diesen Arten von Tests sind manchmal verschwommen. Aus diesem Grund hat Laravel all diese verwirrenden Begriffe vereinfacht und in zwei Kategorien zusammengefasst: Einheit/Funktion.

Einfach ausgedrückt versuchen Funktionstests, die tatsächliche Funktionalität Ihrer Anwendungen auszuführen: die URL abrufen, die API aufrufen und das genaue Verhalten wie das Ausfüllen des Formulars nachahmen. Funktionstests führen in der Regel dieselben oder ähnliche Vorgänge aus, die jeder Projektbenutzer im wirklichen Leben manuell ausführen würde.

Unit-Tests haben zwei Bedeutungen. Im Allgemeinen werden Sie möglicherweise feststellen, dass jeder automatisierte Test als „Unit-Test“ bezeichnet wird und der gesamte Prozess als „Unit-Test“ bezeichnet werden kann. Aber im Kontext von Funktionalität versus Einheit geht es bei diesem Prozess darum, eine bestimmte nicht öffentliche Codeeinheit isoliert zu testen. Sie haben beispielsweise eine Laravel-Klasse mit einer Methode, die etwas berechnet, beispielsweise den Gesamtbestellpreis mit Parametern. Daher würde der Komponententest angeben, ob von dieser Methode (Codeeinheit) mit unterschiedlichen Parametern korrekte Ergebnisse zurückgegeben werden.

Um einen Komponententest zu generieren, müssen Sie ein Flag hinzufügen:

php artisan make:test OrderPriceTest --unit

Der generierte Code ist derselbe wie beim Pre-Unit-TestdefiLaravel-System:

class OrderPriceTest extends TestCase
{
    public function test_example()
    {
        $this->assertTrue(true);
    }
}

Wie Sie sehen, existiert es nicht RefreshDatabase, und das ist eines davon defigängigste Unit-Test-Definitionen: Es berührt die Datenbank nicht, es funktioniert als „Black Box“, isoliert von der laufenden Anwendung.

Um das zuvor erwähnte Beispiel nachzuahmen, stellen wir uns vor, wir hätten eine Serviceklasse OrderPrice.

app/Services/OrderPriceService.php:

class OrderPriceService
{
    public function calculatePrice($productId, $quantity, $tax = 0.0)
    {
        // Some kind of calculation logic
    }
}

Dann könnte der Unit-Test etwa so aussehen:

class OrderPriceTest extends TestCase
{
    public function test_single_product_no_taxes()
    {
        $product = Product::factory()->create(); // generate a fake product
        $price = (new OrderPriceService())->calculatePrice($product->id, 1);
        $this->assertEquals(1, $price);
    }
 
    public function test_single_product_with_taxes()
    {
        $price = (new OrderPriceService())->calculatePrice($product->id, 1, 20);
        $this->assertEquals(1.2, $price);
    }
 
    // More cases with more parameters
}

Nach meiner persönlichen Erfahrung mit Laravel-Projekten handelt es sich bei der überwiegenden Mehrheit der Tests um Feature-Tests und nicht um Unit-Tests. Zuerst müssen Sie testen, ob Ihre Anwendung so funktioniert, wie sie von echten Menschen verwendet werden würde.

Als nächstes können Sie dies tun, wenn Sie über spezielle Berechnungen oder Logik verfügen defiWenn Sie nire als Einheit mit Parametern verwenden, können Sie speziell dafür Unit-Tests erstellen.

Manchmal erfordert das Schreiben von Tests eine Änderung des Codes selbst und eine Umgestaltung, um ihn „testbarer“ zu machen: die Aufteilung der Einheiten in spezielle Klassen oder Methoden.

Wann/wie werden Tests durchgeführt?

Was ist der eigentliche Nutzen davon? php artisan test, wann sollten Sie es ausführen?

Abhängig von Ihrem Geschäftsablauf gibt es unterschiedliche Ansätze. Im Allgemeinen müssen Sie jedoch sicherstellen, dass alle Tests „grün“ (d. h. fehlerfrei) sind, bevor Sie die endgültigen Codeänderungen in das Repository übertragen.

Dann arbeiten Sie lokal an Ihrer Aufgabe, und wenn Sie glauben, dass Sie fertig sind, führen Sie einige Tests durch, um sicherzustellen, dass nichts kaputt ist. Denken Sie daran, dass Ihr Code möglicherweise nicht nur Fehler in Ihrer eigenen Logik verursacht, sondern auch unbeabsichtigt ein anderes Verhalten im Code einer anderen Person, der vor langer Zeit geschrieben wurde, beeinträchtigt.

Wenn wir noch einen Schritt weiter gehen, ist eine Automatisierung möglich viele Dinge. Mit verschiedenen CI/CD-Tools können Sie Tests festlegen, die immer dann ausgeführt werden, wenn jemand Änderungen an einen bestimmten Git-Zweig überträgt oder bevor Code in den Produktionszweig eingefügt wird. Der einfachste Workflow wäre die Verwendung von Github Actions, den ich habe ein separates Video was es beweist.

Was sollten Sie testen?

Es gibt unterschiedliche Meinungen darüber, wie groß die sogenannte „Testabdeckung“ sein sollte: Probieren Sie alle möglichen Operationen und Fälle auf jeder Seite aus oder beschränken Sie die Arbeit auf die wichtigsten Teile.

Tatsächlich stimme ich hier mit den Leuten überein, die automatisierten Tests vorwerfen, dass sie mehr Zeit in Anspruch nehmen, als tatsächliche Vorteile bringen. Dies kann passieren, wenn Sie Tests für jedes einzelne Detail schreiben. Allerdings kann es für Ihr Projekt erforderlich sein: Die Hauptfrage lautet: „Wie hoch ist der Preis potenzieller Fehler?“.

Mit anderen Worten: Sie müssen Ihre Testbemühungen priorisieren, indem Sie die Frage stellen: „Was würde passieren, wenn dieser Code fehlschlägt?“ Wenn Ihr Zahlungssystem Fehler aufweist, wirkt sich dies direkt auf das Geschäft aus. Wenn also die Funktionalität Ihrer Rollen/Berechtigungen beeinträchtigt ist, stellt dies ein großes Sicherheitsproblem dar.

Mir gefällt, wie Matt Stauffer es auf einer Konferenz ausgedrückt hat: „Sie müssen zuerst die Dinge testen, die, wenn sie scheitern, dazu führen würden, dass Sie von Ihrem Job entlassen werden.“ Natürlich ist das übertrieben, aber Sie verstehen schon: Probieren Sie zuerst die wichtigen Dinge aus. Und dann noch andere Funktionen, wenn Sie Zeit haben.

PEST: neue Alternative zu PHPUnit

Alle oben genannten Beispiele basieren auf dem Laravel-VortesttooldefiNacht: PHPUnit . Aber im Laufe der Jahre sind andere Tools im Ökosystem aufgetaucht und eines der neuesten beliebten ist PEST . Erstellt vom offiziellen Laravel-Mitarbeiter Nuno Maduro zielt darauf ab, die Syntax zu vereinfachen und das Schreiben von Code für Tests noch schneller zu machen.

Unter der Haube läuft es su PHPUnit als zusätzliche Ebene, die lediglich versucht, einige sich wiederholende Teile zu minimierendefiEnde des PHPUnit-Codes.

Schauen wir uns ein Beispiel an. Denken Sie an den Pre-Feature-Testkursdefiin Laravel verbracht? Ich werde dich erinnern:

namespace Tests\Feature;
 
use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;
 
class ExampleTest extends TestCase
{
    public function test_the_application_returns_a_successful_response()
    {
        $response = $this->get('/');
 
        $response->assertStatus(200);
    }
}

Wissen Sie, wie der gleiche Test mit PEST aussehen würde?

test('the application returns a successful response')->get('/')->assertStatus(200);

Ja, EINE Codezeile und das war's. Das Ziel von PEST besteht also darin, den Aufwand für Folgendes zu beseitigen:

• Erstellen von Klassen und Methoden für alles;
• Testfallerweiterung;
• Indem Sie Aktionen in separate Zeilen einfügen: In PEST können Sie sie miteinander verketten.

Um einen PEST-Test in Laravel zu generieren, müssen Sie ein zusätzliches Flag angeben:

php artisan make:test HomepageTest --pest

Zum jetzigen Zeitpunkt ist PEST bei Laravel-Entwicklern recht beliebt, aber es ist Ihre persönliche Präferenz, ob Sie dieses zusätzliche Tool verwenden und sich mit seiner Syntax sowie einem PHPUnit-Hinweis vertraut machen.

BlogInnovazione.it