Ich habe Mitte 2015 angefangen, reines PHP zu lernen. Dann habe ich mich mit CodeIgniter 3 und Laravel 5.1 vertraut gemacht. Im Laufe der Jahre ist Laravel mein bevorzugtes Framework und ich bleibe immer noch dabei. Wie bei anderen beliebten PHP-Projekten halte ich PHPUnit für die einzige Wahl für Unit-Tests. Doch 2021 gab es eine kleine Ver?nderung, als Pest kam. Es wurde von Nuno Maduro erstellt – einem Ingenieur bei Laravel, der auch viele tolle Projekte/Pakete erstellt, die in der PHP- und Laravel-Community weit verbreitet sind.

Seit dem allerersten Tag von Pest habe ich mich nicht darum gekümmert, weil PHPUnit für mich ausreicht und ich mich faul fühle, dieses neue Testtool zu erlernen. Aber je mehr die Laravel-Community w?chst, desto mehr Pest wird empfohlen. Viele Laravel-Projekte/-Pakete von Spatie, Livewire, Filament usw. verwenden Pest. Das Problem besteht also darin, dass ich beim Testen damit zusammenh?ngender Dinge auf PHPUnit portieren muss. Ich scheine keine Wahl zu haben. Es ist Zeit für mich, einen Blick auf Pest zu werfen.

Der erste Blick

Nach dem Installationsabschnitt erstelle ich mein erstes PHP-Projekt mit Pest.

mkdir ~/Herd/lerning-pest

cd ~/Herd/learning-pest

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

./vendor/bin/pest --init 

Die Verzeichnisstruktur ist fast die gleiche wie bei PHPUnit. Der Unterschied besteht darin, wie ein Test aussieht. Es ist abschlussbasiert statt klassenbasiert.

<?php

// tests/Unit/ExampleTest.php

test('example', function () {
    expect(true)->toBeTrue();
});

Ich kenne die Verwendung von Closure, mit der Methoden zur Laufzeit tr?ge an ein Objekt angeh?ngt werden k?nnen. Dies kann also in PHPUnit so umgeschrieben werden.

<?php

// tests/Unit/ExampleTest.php

class ExampleTest extends \PHPUnit\Framework\TestCase
{
    public function test_example()
    {
        $this->assertTrue(true);
    }
}

Es hei?t, die Pest-Assertionssyntax sei von Rubys Rspec und Jest inspiriert, was ich nicht kenne. Daher interessiere ich mich auch nicht so sehr für sie. Für mich spielt es keine Rolle, wie die Assertionssyntax ist.

Mir gef?llt einfach das Ergebnis, das beim Ausführen von Tests angezeigt wird. Es ist meiner Meinung nach viel hübscher und sauberer als PHPUnit.

Behauptungen

Dies sind Behauptungen, die ich in PHPUnit am h?ufigsten verwendet habe.

$this->assertSame($expected, $actual);
$this->assertTrue($condition);
$this->assertFalse($condition);
$this->assertNull($actual);
$this->assertEmpty($array);
$this->assertCount($count, $countable);
$this->assertInstanceof($type, $instance);

Sie k?nnen leicht in Pest umgeschrieben werden.

expect($actual)->toBe($expected);
expect($condition)->toBeTrue();
expect($condition)->toBeFalse();
expect($actual)->toBeNull();
expect($actual)->toBeEmpty();
expect($actual)->toBeInstanceOf($type);

Wie ich bereits erw?hnt habe, ist die Pest-Assertionssyntax in Ordnung, aber ich bleibe derzeit bei PHPUnit, weil ich keine neuen APIs studieren muss. Wie auch immer, ich bevorzuge PHPUnit-Behauptungen und verwende nur Dinge, die in Pest einzigartig sind. Architekturtests sind ein Beispiel. Meine Testdatei sieht so aus.

<?php

test("all PHP files in LearningPest namespace must have strict mode enabled", function () {
    arch()
        ->expect('LearningPest')
        ->toUseStrictTypes();
});

test('all PHPUnit assertions are available for Pest', function () {
    $instance = new \stdClass();

    $getInstance = function () use ($instance) {
        return $instance;
    };

    $this->assertSame($instance, $getInstance());

    $this->assertInstanceOf(stdClass::class, $instance);

    $this->assertTrue(1 < 2);
    $this->assertFalse(1 > 2);

    $value = null;

    $this->assertNull($value);

    $this->assertEmpty([]);

    $array = [1, 2, 3];

    $this->assertCount(3, $array);
});

Pflichtfunktionen

Es gibt eine Reihe obligatorischer Funktionen, die es mir erm?glichen, in Pest identisch mit PHPUnit zu arbeiten. Hier sind sie:

• PHPUnit verfügt über einen Datenanbieter. Pest hat Datens?tze.
• PHPUnit verfügt über setUp, TearDown, SetUpBeforeClass und TearDownAfterClass. Pest hat beforeEach, afterEach, beforeAll und afterAll.
• Beide verfügen über Ausnahmeprüfungen und k?nnen Tests überspringen/gruppieren/filtern.

Mockery ist eine eigenst?ndige Bibliothek, daher liste ich sie hier nicht auf.

Auf der anderen Seite verfügt Pest über viele nützliche Dinge wie Architektur, Snapshot- oder Stresstests und Plugins. Ich werde sie entdecken, wenn ich Tests schreibe.

Abschluss

• Pest basiert auf PHPUnit, das in der PHP- und Laravel-Community in letzter Zeit weit verbreitet und empfohlen wird.
• Mit Pest kann ich fast auf die gleiche Weise wie zuvor arbeiten, aber mit sch?nerer CLI und hilfreicheren Funktionen.
• Pest ist jetzt das Standard-Testframework für meine PHP- und Laravel-Anwendungen.

Wenn Sie ein PHP-Entwickler sind, der Pest noch nicht verwendet hat, probieren Sie es aus.

Das obige ist der detaillierte Inhalt vonIch habe schlie?lich Pest für PHP und Laravel ausprobiert und dann den Wechsel vorgenommen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!