J'ai finalement essayé Pest pour PHP et Laravel, puis j'ai changé

J'ai commencé à apprendre le PHP pur mi-2015. Ensuite, je me suis familiarisé avec CodeIgniter 3 et Laravel 5.1. Au fil des années, Laravel est mon framework de prédilection, et je m'y tiens toujours. Comme d'autres projets PHP populaires, je vois que PHPUnit est le seul choix pour les tests unitaires. Mais il y a eu un petit changement en 2021 avec l’arrivée de Pest. Il est créé par Nuno Maduro - un ingénieur chez Laravel, qui réalise également de nombreux projets/packages géniaux largement utilisés dans la communauté PHP et Laravel.

Depuis le tout premier jour de Pest, je m'en fiche car PHPUnit me suffit et j'ai la flemme d'apprendre ce nouvel outil de test. Mais plus la communauté Laravel grandit, plus Pest est recommandé. De nombreux projets/packages Laravel de Spatie, Livewire, Filament, ... utilisent Pest. Le problème est donc que lorsque je teste des éléments qui leur sont liés, je dois effectuer un portage sur PHPUnit. Il me semble que je n'ai pas le choix. Il est temps pour moi de jeter un œil à Pest.

Le premier regard

Suite à la section installation, je crée mon premier projet PHP en utilisant Pest.

mkdir ~/Herd/lerning-pest

cd ~/Herd/learning-pest

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

./vendor/bin/pest --init 

La structure des répertoires est presque la même que celle de PHPUnit. La différence est à quoi ressemble un test. C'est basé sur la fermeture plutôt que sur la classe.

<?php // tests/Unit/ExampleTest.php

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

Je sais utiliser Closure qui peut attacher paresseusement des méthodes à un objet au moment de l'exécution. Donc cela peut être réécrit en PHPUnit comme ça.

<?php // tests/Unit/ExampleTest.php

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

Il est indiqué que la syntaxe d'assertion Pest est inspirée de Rspec et Jest de Ruby, que je ne connais pas. Donc, eux non plus ne m'intéressent pas trop. Pour moi, peu importe la syntaxe des assertions.

J'aime juste le résultat affiché lors de l'exécution des tests. C'est beaucoup plus joli et plus propre que PHPUnit, je pense.

Affirmations

Ce sont les assertions que j'ai le plus utilisées dans PHPUnit.

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

Ils peuvent être facilement réécrits dans Pest.

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

Comme je l'ai mentionné plus tôt, la syntaxe d'assertion Pest est correcte, mais je m'en tiens actuellement à PHPUnit car je n'ai pas besoin d'étudier de nouvelles API. Quoi qu'il en soit, je préfère les assertions PHPUnit et n'utilise que des éléments uniques dans Pest. Les tests d'architecture en sont un exemple. Mon fichier de test ressemble à ceci.

<?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 assertFalse(1 > 2);

    $value = null;

    $this->assertNull($value);

    $this->assertEmpty([]);

    $array = [1, 2, 3];

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

Fonctionnalités obligatoires

Il existe un certain nombre de fonctionnalités obligatoires qui me permettent de travailler dans Pest de la même manière que PHPUnit. Les voici :

• PHPUnit a un fournisseur de données. Pest a des ensembles de données.
• PHPUnit a setUp, TearDown, setUpBeforeClass et TearDownAfterClass. Le ravageur a avantChac, aprèsChacun, avantTout et aprèsTout.
• Les deux ont des contrôles d'exception et peuvent ignorer/regrouper/filtrer les tests.

Mockery est une bibliothèque autonome, donc je ne la liste pas ici.

D'un autre côté, Pest a beaucoup de choses qui peuvent s'avérer utiles, comme l'architecture, les instantanés ou les tests de stress et les plugins. Je les découvrirai lors de la rédaction des tests.

Conclusion

• Pest est construit sur PHPUnit, largement utilisé et recommandé récemment dans la communauté PHP et Laravel.
• En utilisant Pest, je peux travailler presque de la même manière qu'avant, mais avec une CLI plus jolie et des fonctionnalités plus utiles.
• Maintenant, Pest est le framework de test par défaut pour mes applications PHP et Laravel.

Si vous êtes un développeur PHP qui n'a pas utilisé Pest, essayez-le.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!