Pint, Rector, Larastan et Pest : Indispensables pour réussir

Dans le monde du développement web, maintenir la qualité du code et la cohérence à travers l'ensemble du projet est la clé du succès. Plus le projet grandit, plus il devient difficile de maintenir une base de code propre à la main. Heureusement, il existe des outils disponibles pour nous aider à atteindre cet objectif. Dans cet article, nous allons explorer quatre outils essentiels pour tout projet Laravel : Pint, Rector, Larastan et Pest.

1. Pint est un outil de correction de style de code PHP opinionné pour les minimalistes. Il vous aide à maintenir un style de codage cohérent tout au long de votre projet en formatant automatiquement votre code selon des règles prédéfinies. Cela améliore non seulement la lisibilité, mais réduit également les risques d'introduire des bogues dus à des pratiques de codage incohérentes. Dans le monde JS, nous avons Prettier ou ESLint, et Pint est l'équivalent pour PHP.
2. Rector est un outil de refactorisation automatisée de code PHP. Il vous permet d'appliquer automatiquement diverses transformations et améliorations de code, vous faisant gagner du temps. Avec Rector, vous pouvez facilement mettre à niveau votre code vers les dernières normes PHP, supprimer les fonctionnalités obsolètes et appliquer les meilleures pratiques sans avoir à éditer manuellement chaque fichier. Dans le monde JS, il n'y a pas d'équivalent direct à Rector, mais TypeScript et ESLint peuvent être utilisés pour imiter certaines de ses fonctionnalités.
3. Larastan est un outil d'analyse statique pour les applications Laravel. Il vous aide à détecter les bogues et les problèmes potentiels dans votre code avant qu'ils ne deviennent un problème. En analysant votre base de code, Larastan peut identifier les zones qui pourraient entraîner des erreurs d'exécution, vous permettant de les corriger de manière proactive. Cela est particulièrement utile dans les projets plus importants où il peut être difficile de suivre toutes les pièces mobiles. Dans le monde JS, nous avons TypeScript et ESLint, et Larastan est l'équivalent pour PHP.
4. Pest est un framework de test pour PHP qui se concentre sur la simplicité et l'élégance. Il vous permet d'écrire des tests propres et expressifs pour votre application, garantissant que votre code fonctionne comme prévu. En utilisant Pest, vous pouvez facilement créer des tests unitaires, des tests fonctionnels et même des tests d'interface, tout en maintenant une syntaxe propre et lisible. Dans le monde JS, nous avons Jest, et Pest est l'équivalent pour PHP.

En intégrant ces quatre outils dans votre projet Laravel dès le départ, vous pouvez vous assurer que votre code reste propre, cohérent et presque exempt de bogues. Cela vous fera non seulement gagner du temps et des efforts à long terme, mais facilitera également la compréhension et la contribution d'autres développeurs à votre projet. Un gagnant-gagnant pour tout le monde !

Pint ​

Pint est préinstallé avec Laravel, donc vous n'avez pas besoin de l'installer manuellement. Mais pour avoir la meilleure expérience, nous devons le configurer et ajouter une commande personnalisée pour formater notre code.

Pour la configuration, nous allons créer un fichier pint.json à la racine de notre projet. Ce fichier de configuration nous permettra de spécifier des règles et des exceptions pour notre style de code, garantissant la cohérence à travers l'ensemble de la base de code.

{
  "preset": "laravel",
  "rules": {
    "array_push": true,
    "backtick_to_shell_exec": true,
    "date_time_immutable": true,
    "declare_strict_types": true,
    "lowercase_keywords": true,
    "lowercase_static_reference": true,
    "final_class": true,
    "final_internal_class": true,
    "final_public_method_for_abstract_class": true,
    "fully_qualified_strict_types": true,
    "global_namespace_import": {
      "import_classes": true,
      "import_constants": true,
      "import_functions": true
    },
    "mb_str_functions": true,
    "modernize_types_casting": true,
    "new_with_parentheses": false,
    "no_superfluous_elseif": true,
    "no_useless_else": true,
    "no_multiple_statements_per_line": true,
    "ordered_class_elements": {
      "order": [
        "use_trait",
        "case",
        "constant",
        "constant_public",
        "constant_protected",
        "constant_private",
        "property_public",
        "property_protected",
        "property_private",
        "construct",
        "destruct",
        "magic",
        "phpunit",
        "method_abstract",
        "method_public_static",
        "method_public",
        "method_protected_static",
        "method_protected",
        "method_private_static",
        "method_private"
      ],
      "sort_algorithm": "none"
    },
    "ordered_interfaces": true,
    "ordered_traits": true,
    "protected_to_private": true,
    "self_accessor": true,
    "self_static_accessor": true,
    "strict_comparison": true,
    "visibility_required": true
  }
}

Décomposons la configuration :

• preset : Cette option vous permet de choisir une configuration prédéfinie pour Pint. Dans ce cas, nous utilisons le preset laravel, qui est livré avec un ensemble de règles recommandées pour les projets Laravel.
• rules : Cette section contient les règles spécifiques que nous voulons appliquer à notre base de code. Chaque règle peut être définie sur true ou false, selon que nous souhaitons l'activer ou la désactiver.
• array_push : Imposer l'utilisation de la syntaxe de push de tableau au lieu de la syntaxe de fusion de tableau.
• backtick_to_shell_exec : Convertit les backticks en fonction shell_exec.
• date_time_immutable : Imposer l'utilisation d'objets date et heure immuables.
• declare_strict_types : Imposer l'utilisation de types stricts dans les fichiers PHP.
• lowercase_keywords : Imposer l'utilisation de mots-clés en minuscules dans PHP.
• lowercase_static_reference : Imposer l'utilisation de références statiques en minuscules dans PHP.
• final_class : Imposer l'utilisation de classes finales.
• final_internal_class : Imposer l'utilisation de classes finales pour les classes internes.
• final_public_method_for_abstract_class : Imposer l'utilisation de méthodes publiques finales pour les classes abstraites.
• fully_qualified_strict_types : Imposer l'utilisation de types strictement qualifiés dans les fichiers PHP.
• global_namespace_import : Imposer l'utilisation d'importations d'espace de noms globales pour les classes, les constantes et les fonctions.
• mb_str_functions : Imposer l'utilisation de fonctions de chaîne multibyte.
• modernize_types_casting : Imposer l'utilisation de conversion de type moderne dans PHP.
• new_with_parentheses : Imposer l'utilisation de parenthèses lors de la création de nouveaux objets.
• no_superfluous_elseif : Imposer la suppression des instructions elseif superflues.
• no_useless_else : Imposer la suppression des instructions else inutiles.
• no_multiple_statements_per_line : Imposer l'utilisation d'une seule instruction par ligne.
• ordered_class_elements : Imposer l'ordre des éléments de classe, tels que traits, constantes, propriétés et méthodes.
• ordered_interfaces : Imposer l'ordre des interfaces.
• ordered_traits : Imposer l'ordre des traits.
• protected_to_private : Imposer l'utilisation de la visibilité privée pour les propriétés et les méthodes.
• self_accessor : Imposer l'utilisation de Self pour accéder aux propriétés et méthodes.
• self_static_accessor : Imposer l'utilisation d'accès statiques Self pour les propriétés et méthodes.
• strict_comparison : Imposer l'utilisation des opérateurs de comparaison stricts.
• visibility_required : Imposer l'utilisation de mots-clés de visibilité pour les propriétés et les méthodes.

Maintenant, ajoutons une commande personnalisée pour vérifier notre code. Nous allons ajouter une commande lint à notre fichier composer.json :

{
  "scripts": {
    "lint": "pint"
  }
}

Désormais, nous pouvons exécuter composer lint pour vérifier notre code. Il analysera automatiquement tous les fichiers dans les dossiers app, config, database et routes pour s'assurer que tout est propre et cohérent.

Vous devriez voir quelque chose comme ceci :

➜ composer lint
> pint

  ✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓

  ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── Laravel
    FIXED   ......................................................................................................................... 26 fichiers, 26 problèmes de style corrigés
  ✓ app/Http/Controllers/Controller.php                                                                            declare_strict_types, blank_line_after_opening_tag
  ✓ app/Models/User.php                                                                               final_class, declare_strict_types, blank_line_after_opening_tag
  ✓ app/Providers/AppServiceProvider.php                                                              final_class, declare_strict_types, blank_line_after_opening_tag
  ✓ bootstrap/app.php                                                                                              declare_strict_types, blank_line_after_opening_tag
  ✓ bootstrap/providers.php                                                                                        declare_strict_types, blank_line_after_opening_tag
  ✓ config/app.php                                                                                                 declare_strict_types, blank_line_after_opening_tag
  ✓ config/auth.php                                                                                                declare_strict_types, blank_line_after_opening_tag
  ✓ config/cache.php                                                                                               declare_strict_types, blank_line_after_opening_tag
  ✓ config/database.php                                                                                            declare_strict_types, blank_line_after_opening_tag
  ✓ config/filesystems.php                                                                                         declare_strict_types, blank_line_after_opening_tag
  ✓ config/logging.php                                                                                             declare_strict_types, blank_line_after_opening_tag
  ✓ config/mail.php                                                                                                declare_strict_types, blank_line_after_opening_tag
  ✓ config/queue.php                                                                                               declare_strict_types, blank_line_after_opening_tag
  ✓ config/services.php                                                                                            declare_strict_types, blank_line_after_opening_tag
  ✓ config/session.php                                                                                             declare_strict_types, blank_line_after_opening_tag
  ✓ database/factories/UserFactory.php                                          final_class, self_static_accessor, declare_strict_types, blank_line_after_opening_tag
  ✓ database/migrations/0001_01_01_000000_create_users_table.php                class_definition, declare_strict_types, blank_line_after_opening_tag, braces_position
  ✓ database/migrations/0001_01_01_000001_create_cache_table.php                class_definition, declare_strict_types, blank_line_after_opening_tag, braces_position
  ✓ database/migrations/0001_01_01_000002_create_jobs_table.php                 class_definition, declare_strict_types, blank_line_after_opening_tag, braces_position
  ✓ database/seeders/DatabaseSeeder.php                                                               final_class, declare_strict_types, blank_line_after_opening_tag
  ✓ public/index.php                                                                                               declare_strict_types, blank_line_after_opening_tag
  ✓ routes/console.php                                                                                             declare_strict_types, blank_line_after_opening_tag
  ✓ routes/web.php                                                                                                 declare_strict_types, blank_line_after_opening_tag
  ✓ tests/Feature/ExampleTest.php                                                                                  declare_strict_types, blank_line_after_opening_tag
  ✓ tests/TestCase.php                                                                                             declare_strict_types, blank_line_after_opening_tag
  ✓ tests/Unit/ExampleTest.php                                                                                     declare_strict_types, blank_line_after_opening_tag

Comment devez-vous interpréter cette sortie ? Tout d'abord, vous voyez le nom du fichier, suivi des règles qui lui ont été appliquées. Si vous voyez un ✓, cela signifie que Pint a formaté le fichier avec succès ; sinon, vous verrez un simple . si le fichier était déjà bien formaté.

Ce n'est pas tout ! Nous allons ajouter une deuxième commande appelée test:lint. Ce script sera utilisé dans notre CI pour s'assurer que tout est correctement formaté. Au lieu de corriger automatiquement le code, cette commande générera une erreur si le code n'est pas bien formaté.

{
  "scripts": {
    "lint": "pint",
    "test:lint": "pint --test"
  }
}

Parfait !

Rector ​

Le deuxième outil que nous allons utiliser est Rector, et il complète naturellement Pint. Tandis que Pint est utilisé pour formater le code, Rector est utilisé pour refactoriser automatiquement le code. Par exemple, le code suivant :

class SomeClass
{
    public function getValue(int $number)
    {
        if ($number) {
            return 100;
        }

        return 500;
    }
}

Serait refactorisé ainsi :

final class SomeClass
{
    public function getValue(int $number): int
    {
        return $number ? 100 : 500;
    }
}

En appliquant la règle ReturnTypeFromStrictTernaryRector.

Installons Rector avec Composer :

composer require rector/rector --dev

Créez un fichier de configuration rector.php :

<?php

declare(strict_types=1);

use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([
        __DIR__.'/app',
        __DIR__.'/bootstrap/app.php',
        __DIR__.'/config',
        __DIR__.'/database',
        __DIR__.'/public',
    ])
    ->withPreparedSets(
        deadCode: true,
        codeQuality: true,
        typeDeclarations: true,
        privatization: true,
        earlyReturn: true,
        strictBooleans: true,
    )
    ->withPhpSets();

Ce fichier de configuration est un peu plus complexe que celui de Pint. Décomposons-le :

• declare(strict_types=1) : Cette ligne active le typage strict dans le fichier, garantissant que PHP applique les déclarations de type.
• use Rector\Config\RectorConfig : Cette ligne importe la classe RectorConfig, qui est utilisée pour configurer Rector.
• return RectorConfig::configure() : Cette ligne commence le processus de configuration pour Rector.
• ->withPaths([...]) : Cette méthode spécifie les chemins vers les répertoires et les fichiers que Rector doit analyser et refactoriser. Dans ce cas, nous incluons les répertoires app, bootstrap/app.php, config, database et public.
• ->withPreparedSets(...) : Cette méthode vous permet d'activer des ensembles de règles prédéfinis pour Rector. Dans ce cas, nous activons plusieurs ensembles :
  • deadCode : Supprime le code mort du projet.
  • codeQuality : Améliore la qualité du code en appliquant diverses meilleures pratiques.
  • typeDeclarations : Ajoute des déclarations de type aux fonctions et méthodes.
  • privatization : Rend les propriétés et méthodes privées lorsque cela est possible.
  • earlyReturn : Applique des schémas de retour anticipé pour améliorer la lisibilité.
  • strictBooleans : Imposer des comparaisons booléennes strictes.
• ->withPhpSets() : Cette méthode active un ensemble de règles spécifiquement conçues pour PHP.

Maintenant, ajoutons une commande personnalisée à notre fichier composer.json :

{
  "scripts": {
    "refactor": "rector"
  }
}

Finalement, nous pouvons exécuter composer refactor pour refactoriser notre code. Cela refactorisera automatiquement tous les fichiers dans les dossiers app, bootstrap/app.php, config, database et public pour s'assurer que tout est propre et cohérent. Vous devriez voir quelque chose comme ceci :

➜ composer refactor
> rector
 20/20 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%
8 fichiers avec des modifications
====================

1) database/migrations/0001_01_01_000001_create_cache_table.php:12

    ---------- begin diff ----------
@@ @@
      */
     public function up(): void
     {
-        Schema::create('cache', function (Blueprint $table) {
+        Schema::create('cache', function (Blueprint $table): void {
             $table->string('key')->primary();
             $table->mediumText('value');
             $table->integer('expiration');
         });

-        Schema::create('cache_locks', function (Blueprint $table) {
+        Schema::create('cache_locks', function (Blueprint $table): void {
             $table->string('key')->primary();
             $table->string('owner');
             $table->integer('expiration');
    ----------- end diff -----------

Règles appliquées :
 * AddClosureVoidReturnTypeWhereNoReturnRector
#  ...

La sortie montre les fichiers qui ont été modifiés avec un diff des changements et les différentes règles appliquées au fichier. Simple et tellement puissant !

Mais ce n'est pas tout ! Encore une fois, nous allons ajouter une deuxième commande appelée test:refactor. Ce script sera utilisé dans notre CI pour s'assurer que tout est bien refactorisé. Au lieu de refactoriser automatiquement le code, cette commande générera simplement une erreur si le code n'est pas bien refactorisé.

{
  "scripts": {
    "refactor": "rector",
    "test:refactor": "rector --dry-run"
  }
}

Larastan ​

Installez Larastan avec Composer :

composer require --dev "larastan/larastan:^3.0"

Créez un fichier phpstan.neon :

includes:
  - vendor/larastan/larastan/extension.neon
  - vendor/phpstan/phpstan/conf/bleedingEdge.neon

parameters:
  level: 6

  paths:
    - app
    - config
    - bootstrap
    - database/factories
    - routes

Ce fichier de configuration est un peu plus complexe que celui de Pint. Décomposons-le :

• includes : Cette section inclut des fichiers de configuration supplémentaires qui étendent la fonctionnalité de Larastan. Dans ce cas, nous incluons le fichier larastan/larastan/extension.neon et le fichier phpstan/phpstan/conf/bleedingEdge.neon.
• parameters : Cette section contient les principaux paramètres de configuration pour Larastan.
• level : Ce paramètre définit le niveau de rigueur pour l'analyse. Des niveaux plus élevés détecteront plus de problèmes potentiels mais peuvent également produire plus de faux positifs. Dans ce cas, nous utilisons le niveau 6, qui est un bon équilibre entre rigueur et utilisabilité. Plus le niveau est strict, plus vous obtiendrez d'erreurs et plus de temps vous devrez passer à les corriger. Honnêtement, je recommande de commencer par le niveau 2 et progressivement, lorsque vous vous habituerez à Larastan et à ses règles, d'augmenter le niveau.
• paths : Ce paramètre spécifie les chemins vers les répertoires et les fichiers que Larastan doit analyser. Dans ce cas, nous incluons les répertoires app, config, bootstrap, database/factories, et routes.

Maintenant, ajoutons une commande personnalisée à notre fichier composer.json :

{
  "scripts": {
    "test:types": "phpstan analyse"
  }
}

Contrairement à Pint et Rector, Larastan n'est pas automatique et ne peut pas réparer le code pour vous. Au lieu de cela, il générera des erreurs et des avertissements que vous devrez corriger manuellement.

Nous pouvons exécuter composer test:types pour analyser notre code. Cela analysera automatiquement tous les fichiers dans les dossiers app, config, bootstrap, database/factories, et routes pour s'assurer que tout est propre et cohérent. Vous devriez voir quelque chose comme ceci :

➜ composer test:types
> phpstan analyse
Note: Using configuration file /Users/esoub/dev/p/mimram/phpstan.neon.
 20/20 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%

 ------ ---------------------------
  Line   routes/console.php
 ------ ---------------------------
  :9     Undefined variable: $this
         🪪  variable.undefined
 ------ ---------------------------

 [ERROR] Found 1 error

Script phpstan analyse handling the test:types event returned with error code 1

Oh non ! Nous avons une erreur dans notre fichier routes/console.php. Pour la corriger, nous pouvons simplement supprimer la commande personnalisée du fichier car nous n'en avons pas besoin.

<?php

use Illuminate\Foundation\Inspiring; 
use Illuminate\Support\Facades\Artisan; 

Artisan::command('inspire', function () { 
    $this->comment(Inspiring::quote()); 
})->purpose('Afficher une citation inspirante'); 

Maintenant, exécutons à nouveau composer test:types :

➜ composer test:types
> phpstan analyse
Note : Utilisation du fichier de configuration /Users/esoub/dev/p/mimram/phpstan.neon.
 20/20 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%

 [OK] Pas d'erreurs

Pest ​

Le dernier outil que nous allons utiliser est Pest. Pest est un framework de test pour PHP qui se concentre sur la simplicité et l'élégance. Il vous permet d'écrire des tests propres et expressifs pour votre application, garantissant que votre code fonctionne comme prévu. Pest est le framework de test par défaut dans tout nouveau projet Laravel, vous n'avez donc pas besoin de l'installer manuellement.

Cependant, nous allons le configurer et ajouter quelques commandes personnalisées à notre fichier composer.json.

Tout d'abord, modifions le fichier phpunit.xml :

<?xml version="1.0" encoding="UTF-8"?>
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="vendor/phpunit/phpunit/phpunit.xsd"
         bootstrap="vendor/autoload.php"
         colors="true"
>
    <testsuites>
        <testsuite name="Http">
            <directory>tests/Http</directory>
        </testsuite>
        <testsuite name="Unit">
            <directory>tests/Unit</directory>
        </testsuite>
    </testsuites>
    <source>
        <include>
            <directory>app</directory>
            <directory>config</directory>
            <directory>routes</directory>
        </include>
    </source>
    <php>
        <env name="APP_ENV" value="testing"/>
        <env name="APP_MAINTENANCE_DRIVER" value="file"/>
        <env name="BCRYPT_ROUNDS" value="4"/>
        <env name="CACHE_STORE" value="array"/>
        <env name="DB_CONNECTION" value="sqlite"/>
        <env name="DB_DATABASE" value=":memory:"/>
        <env name="MAIL_MAILER" value="array"/>
        <env name="PULSE_ENABLED" value="false"/>
        <env name="QUEUE_CONNECTION" value="sync"/>
        <env name="SESSION_DRIVER" value="array"/>
        <env name="TELESCOPE_ENABLED" value="false"/>
    </php>
</phpunit>

Ce fichier de configuration est un peu plus complexe que celui de Pint. Décomposons-le :

• <?xml version="1.0" encoding="UTF-8"?> : Cette ligne spécifie la version XML et l'encodage.
• <phpunit ...> : Cette ligne démarre la configuration PHPUnit.
• xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" : Cet attribut spécifie l'espace de noms XML pour l'instance de schéma.
• xsi:noNamespaceSchemaLocation="vendor/phpunit/phpunit/phpunit.xsd" : Cet attribut spécifie l'emplacement du schéma XML pour PHPUnit.
• bootstrap="vendor/autoload.php" : Cet attribut spécifie le fichier de bootstrap pour PHPUnit, qui est responsable du chargement des dépendances nécessaires.
• colors="true" : Cet attribut active la sortie colorée dans la console.
• <testsuites> : Cette section définit les ensembles de tests pour le projet.
• <testsuite name="Http"> : Cette ligne définit un ensemble de tests nommé "Http".
• <directory>tests/Http</directory> : Cette ligne spécifie le répertoire contenant les tests pour l'ensemble de tests "Http".
• <testsuite name="Unit"> : Cette ligne définit un ensemble de tests nommé "Unit".
• <directory>tests/Unit</directory> : Cette ligne spécifie le répertoire contenant les tests pour l'ensemble de tests "Unit".
• <source> : Cette section définit les répertoires sources pour le projet.
• <include> : Cette section inclut les répertoires spécifiés dans la source.
• <directory>app</directory> : Cette ligne spécifie le répertoire app comme répertoire source.
• <directory>config</directory> : Cette ligne spécifie le répertoire config comme répertoire source.
• <directory>routes</directory> : Cette ligne spécifie le répertoire routes comme répertoire source.
• <php> : Cette section définit les variables d'environnement PHP pour le projet.
• <env name="APP_ENV" value="testing"/> : Cette ligne définit la variable d'environnement APP_ENV sur testing.
• <env name="APP_MAINTENANCE_DRIVER" value="file"/> : Cette ligne définit la variable d'environnement APP_MAINTENANCE_DRIVER sur file.
• <env name="BCRYPT_ROUNDS" value="4"/> : Cette ligne définit la variable d'environnement BCRYPT_ROUNDS sur 4.
• <env name="CACHE_STORE" value="array"/> : Cette ligne définit la variable d'environnement CACHE_STORE sur array.
• <env name="DB_CONNECTION" value="sqlite"/> : Cette ligne définit la variable d'environnement DB_CONNECTION sur sqlite.
• <env name="DB_DATABASE" value=":memory:"/> : Cette ligne définit la variable d'environnement DB_DATABASE sur :memory:.
• <env name="MAIL_MAILER" value="array"/> : Cette ligne définit la variable d'environnement MAIL_MAILER sur array.
• <env name="PULSE_ENABLED" value="false"/> : Cette ligne définit la variable d'environnement PULSE_ENABLED sur false.
• <env name="QUEUE_CONNECTION" value="sync"/> : Cette ligne définit la variable d'environnement QUEUE_CONNECTION sur sync.
• <env name="SESSION_DRIVER" value="array"/> : Cette ligne définit la variable d'environnement SESSION_DRIVER sur array.
• <env name="TELESCOPE_ENABLED" value="false"/> : Cette ligne définit la variable d'environnement TELESCOPE_ENABLED sur false.

Toutes ces variables sont très importantes pour garantir que les tests se déroulent sans accroc dans un environnement prévisible. Cela limite les instabilités des tests et simplifie l'infrastructure pour les faire fonctionner.

Comme nous avons changé le dossier pour nos tests d'intégration de Feature à Http, nous devons renommer le dossier tests/Feature en tests/Http.

mv tests/Feature/** tests/Http/** && sed -i '' 's/Feature/Http/g' tests/Pest.php

Dans le dossier des tests, nous avons maintenant deux dossiers et deux fichiers :

1. tests/Http : Ce dossier contient les tests d'intégration de l'application.
2. tests/Unit : Ce dossier contient les tests unitaires de l'application.
3. tests/Pest.php : Ce fichier contient la configuration de Pest.
4. tests/TestCase.php : Ce fichier contient le cas de test de base pour l'application.

Enfin, ajoutons quelques commandes personnalisées à notre fichier composer.json :

{
  "scripts": {
    "test:type-coverage": "pest --type-coverage --min=100",
    "test:unit": "pest --parallel --coverage --min=100",
    "test": [
      "@test:lint",
      "@test:refactor",
      "@test:types",
      "@test:type-coverage",
      "@test:unit"
    ]
  }
}

Les commandes sont :

• test:type-coverage : Cette commande exécute les tests avec une couverture de type et garantit que tous les types sont présents partout, grâce à l'option --min=100.
• test:unit : Cette commande exécute les tests unitaires avec couverture et garantit que toutes les lignes sont couvertes, grâce aux options --coverage et --min=100.
• test : Cette commande exécute tous les tests, y compris le linting, la refactorisation, le contrôle des types, la couverture des types et les tests unitaires. Cette commande tout-en-un sera utilisée dans notre CI. Si cette commande réussit, notre confiance dans le code sera à son maximum.

Pour que la commande test:type-coverage fonctionne, nous devons installer un plugin pour Pest :

composer require pestphp/pest-plugin-type-coverage --dev

Réflexions finales ​

Le combo Pint plus Rector est un véritable must-have pour tout projet Laravel. Il vous permet de vous concentrer sur l'écriture de code au lieu de le formater et de vous assurer qu'il est écrit selon les dernières normes. Honnêtement, je ne peux pas imaginer travailler sans.

Larastan est absolument indispensable pour attraper les erreurs potentielles de type avant qu'elles ne deviennent un problème. C'est un outil un peu plus complexe à comprendre, surtout la sortie qui peut parfois être un peu cryptique, mais il est tellement puissant que comme pour Pint et Rector, je ne peux pas imaginer travailler sans.

Et enfin, Pest rend l'écriture de tests tellement agréable et propre. Il reflète clairement l'état d'esprit de la communauté Laravel : simplicité et élégance.

J'espère que vous avez apprécié cet article et que vous avez appris quelque chose de nouveau. Si vous avez des questions, n'hésitez pas à demander dans les commentaires.