Contrôlez votre refactorisation de l'héritage avec les tests d'architecture PEST

PEST est né de l'imagination de Nuno Maduro et Luke Dowling en 2021, avec pour mission d'apporter le style de test JEST du monde JavaScript dans le monde PHP à travers Laravel. Depuis, il y a eu deux versions majeures du projet et beaucoup de nouvelles fonctionnalités à faire sourciller.

Pour moi, c'était l'introduction de l'architecture des tests que je n'avais jamais vus auparavant. Bien sûr, vous devriez écrire des tests pour absolument tout ce que vous faites (et vous devriez le faire !), mais quelle serait l'utilité d'écrire des tests sur la structure même de l'application ? Eh bien, si l'on part d'un projet entièrement nouveau, il n'y a probablement pas grand-chose à faire. Mais c'est là que la beauté de la chose est apparue : qu'en est-il de l'introduction de ces tests dans une vieille assiette de spaghettis qui a besoin d'une refonte gérée ? C'est maintenant que nous parlons ! Dans cet article, nous allons examiner les points de départ les plus faciles pour lancer une refonte de l'existant avec le test d'architecture PEST.

Un pour les responsables de l'ingénierie

Quel genre de choses peut-elle faire ? Eh bien, en utilisant la fonction arch() nous pouvons faire plusieurs choses avec l'API PEST Expectation :

• Définir où les classes peuvent être étendues et quand elles ne le peuvent pas

• Définir l'emplacement de vos interfaces

• Définir les classes qui doivent ou ne doivent pas utiliser les traits

• Refonte de l'accidentel die() ou dump() avant que quelque chose comme PHPStan/Psalm ne soit déclenché

• Faites en sorte que votre application respecte les conventions de nommage de Laravel.

C'est beaucoup de choses prêtes à l'emploi. Disons que vous héritez d'un nouveau projet et qu'en une heure, vous pouvez commencer le remaniement avec des tests de haut niveau. Le scénario idéal que vous souhaiteriez avoir en arrivant dans une base de code patrimoniale serait donc le suivant :

• Rédiger le guide de style sur l'aspect et le fonctionnement de la logique de la nouvelle application.

• Commencez à rédiger des tests PEST qui échouent pour mettre en œuvre cette mesure.

D'une certaine manière, je pense que ce qui est proposé est une réimplémentation du développement guidé par le comportement. Considérez le guide de style comme vos tests de type Gherkin, que vous traduisez ensuite en tests unitaires et d'intégration dans PEST.

Montrer l'exemple

Tout ceci est académique sans exemples, alors prenons la théorie que vous avez une base de code Laravel héritée. Avant que les tests n'entrent en jeu, vous voudrez soit utiliser un outil d'auto-refactoring comme RectorPHP pour définir des règles PHP qui ramèneront le code aux conventions modernes, soit utiliser Laravel Shift. A partir de là, nous pouvons introduire PEST en utilisant composer :

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

Vous pouvez alors initialiser une nouvelle configuration PEST :

./vendor/bin/pest --init

Cela créera votre fichier Pest.php qui, si vous êtes familier avec PHPUnit, est l'équivalent du fichier de configuration phpunit.xml. Il est temps de se mettre au travail.

Euh, et après ?

Does Your Code Look Like This?La voici. La raison pour laquelle vous faites carrière dans la technologie. Vous vivez pour avoir hérité d'une application Laravel vieille de 15 ans qui a des routes de débogage exposant complètement les commandes CLI de base, vous avez des dépendances circulaires, et vous avez probablement DB::raw('SELECT * FROM nightmare WHERE refactoring = 1') ; un peu partout.

Créons une règle selon laquelle toute commande de débogage introduite accidentellement dans la base de code doit être supprimée avant que des progrès puissent être réalisés. C'est un strict minimum, n'est-ce pas ? Cette règle est intégrée dans PEST, alors créez d'abord un test en ligne de commande à l'aide de la console :

php artisan pest:test DebbugingRulesetTest

Exécutez le programme de test :

php artisan test

Vous remarquerez qu'il échouera, car PEST a tenté d'adapter le code. Naviguez jusqu'au fichier de test DebuggingRulesetTest.php et remplacez le code comme suit

<?php

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

Exécutez les tests, et étant donné que vous avez hérité d'un désordre théorique, je m'attends à ce que PEST commence à se plaindre de vous : je m'attends à ce que PEST commence à se plaindre.

Whoops, No Debugging Code Here, Please!

Alt :

Nous avons sécurisé la première règle de refactorisation, maintenant nous devons l'appliquer. Il y a plusieurs façons de le faire ; dans les environnements de production, il est courant qu'un gestionnaire d'intégration continue tel que Bitbucket Pipelines d'Atlassian, CI/CD de Gitlab, ou Actions de GitHub déclenche des règles pour pouvoir fusionner les Pull Requests. Nous allons cependant mettre en place les règles les plus strictes, où vous ne pouvez même pas faire de commit sur le code sans que PEST soit satisfait.

Cela se fait par l'intermédiaire des hooks git. Créez un nouveau hook de pré-commission avec cette commande :

cd my-code/.git/hooks

// Windows Users Only
echo. > pre-commit

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

Ouvrir le pré-commission créé à l'étape précédente dans un éditeur de texte ou un IDE, et ajoutez le code pour exécuter PEST :

#!/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

Les pre-commit est un nom de fichier réservé que git consulte pour diverses actions - dans ce cas, quel que soit le contenu de ce fichier, il sera exécuté chaque fois qu'un utilisateur tentera d'effectuer un commit dans la base de code.

Allez-y, essayez de modifier le code et regardez ce qui se passe !

Cela nous permet de lancer notre refactorisation comme point de départ. Nous avons couvert la configuration, il ne reste plus qu'à utiliser les méthodes de l'API de test d'architecture PEST. Dans notre test, nous pouvons ajouter quelques règles de haut niveau :

<?php

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

J'ai ajouté quelques règles, que vous pouvez voir en détail dans le code source de PEST. La première, security(), vous aidera beaucoup dans votre refactorisation initiale : elle s'occupe de faire échouer votre code et d'identifier où il y a de sérieuses failles de sécurité. Celles-ci incluent l'utilisation des méthodes de la bibliothèque standard de PHP qui ont été supprimées pour des raisons de sécurité, telles que

• md5() : Les utilisations de type MD5 doivent vraiment être remplacées par SHA256, donc si vous avez des données telles que des identifiants de session ou des identifiants uniques de base de données, elles doivent être refaites comme pour l'ETL.

• rand() : La fonction aléatoire originale de PHP n'est pas réellement aléatoire

• shell_exec() : Appeler l'interpréteur de commandes de la machine hôte est probablement la pire chose que vous puissiez faire. Vous aurez besoin de le faire, bien sûr, à un moment donné, mais l'idée ici est que vous utilisez la console de Laravel et les méthodes enveloppées pour la sécurité plutôt que de laisser un code hérité déchiqueter votre serveur de façon rampante

Compte tenu du nombre de règles contenues dans ces seuls points de départ, je pense que cela représente deux sprints de refonte ! Je pense qu'il y a toutes sortes de choses que l'on peut faire avec cela, étant donné que PEST permet une pléthore de tests dans l'API Expectation.

Conclusion

En plus des tests d'architecture, PEST 3 a également introduit les tests de mutation, ce qui sera l'objet d'un autre article. La quantité de fonctionnalités fournies par PEST constitue un arsenal complet d'outils pour ceux qui s'occupent de projets hérités. Chez Vonage, nous sommes passionnés par les tests, alors si vous voulez discuter de PHP avec nous ? Rejoignez notre communauté de développeurs communauté de développeurs sur Slackou suivez-nous sur X (anciennement Twitter), ou abonnez-vous à notre lettre d'information aux développeurs. Restez en contact, partagez vos progrès et tenez-vous au courant des dernières nouvelles, astuces et événements pour les développeurs !