Mise en place d’une stratégie de test

1. Introduction

Les tests unitaires permettent de vérifier une fonction ou un morceau de programme de manière atomique. Autrement dit, les tests unitaires assurent qu’une procédure se déroule bien comme prévu, peu importe son contexte.

Pour tester une fonction de manière unitaire, on écrira donc généralement une ou plusieurs fonctions de tests en miroir qui devront être le plus exhaustives possible. De la même manière, pour tester une classe, on créera un ensemble de tests unitaires qui couvrira l’ensemble des méthodes.

2. Créer un test unitaire

Un test unitaire vérifie le fonctionnement d’une portion de programme. Nous allons tester une fonction centToEuro d’un modèle Invoice, qui convertit un entier représentant un nombre de centimes en une chaîne de caractères avec deux chiffres après la virgule représentant des euros, telle que définie ci-dessous :

Fonction centToEuro

public function centToEuro(int $cents): string 
{ 
 
    return number_format($cents / 100, 2, ',', ' '); 
 
}  

On attend donc de cette fonction qu’elle ait le comportement suivant :

Le comportement est connu par contrat. C’est-à-dire que le comportement attendu est défini et connu par la personne qui a développé cette fonction. Il va maintenant falloir coder ce contrat en tant que test unitaire.

Création du modèle invoice et du test unitaire...

1. Configuration

Les tests ne doivent pas être dépendants de la configuration d’un poste de travail en particulier : les tests doivent être exécutables depuis le poste de n’importe quelle personne de l’équipe de développement, mais également sur une machine d’intégration continue (l’intégration continue sera étudiée rapidement en fin de chapitre). Il faut donc que ces tests aient une configuration propre. Cela évitera également de polluer la base de données d’un poste de travail avec des données de test.

Par défaut, Laravel Sail crée une base de données dédiée aux tests. Ainsi, la base de données utilisée en local par le développeur n’est pas impactée. Cette configuration se situe dans le fichier phpunit.xml présent à la racine du projet.

2. Migrations et transactions

Les tests devant être indépendants les uns des autres, Laravel propose un mécanisme pour créer toutes les tables de la base de données avant chaque test et les supprimer ensuite. En d’autres termes, pour chaque méthode de test, le framework lancera toutes les migrations, exécutera le test, puis lancera l’annulation de toutes les migrations afin de retrouver une base vierge pour le test suivant. La base de données sera ainsi toujours...

1. Introduction

Au-delà de traiter des fonctions une par une avec les tests unitaires, il est également possible de tester les fonctionnalités intégrées les unes avec les autres, pour vérifier le comportement d’un ensemble qui fait sens.

Souvent appelé test d’intégration, ce type de vérification valide le fonctionnement d’une partie de l’application sous la forme d’un scénario. Par exemple, on peut souhaiter vérifier qu’une page peut effectivement être chargée pour une route donnée ou qu’un utilisateur est créé dans la base de données lorsqu’un formulaire d’inscription est soumis avec les bons paramètres.

2. Créer un test de fonctionnalité

Avant de créer vos propres tests en utilisant la commande Artisan make:test, une bonne façon d’apprendre à tester son application est de s’inspirer de tests déjà écrits par la communauté de Laravel. Nous allons regarder comment le package Laravel Breeze est testé. Pour l’installer, vous pouvez vous référer au chapitre Authentification et autorisations. Une fois installé, on peut constater que la commande sail test exécute, en plus de nos tests, les tests associés au package.

Test de l’affichage du login, classe Tests\feature\auth\AuthenticationTest

public function test_login_screen_can_be_rendered():...

1. Introduction

Tester le front-end d’une application web de manière automatisée est souvent une tâche difficile. Peu de frameworks fournissent des outils simples à utiliser pour y arriver. Laravel Dusk permet de tester une application dans des conditions réalistes, proches de l’expérience réelle des utilisateurs. Pour cela, Dusk utilise ChromeDriver, qui permet de piloter un navigateur Chrome sur le poste de travail ou la machine de test. C’est-à-dire qu’un navigateur est réellement lancé et piloté par le code et qu’il suivra donc le scénario rédigé. Cela permet de réaliser en quelques secondes ce qui aurait pris des heures à une équipe de testeurs, pour un résultat identique, voire parfois meilleur.

En quelque sorte, Laravel Dusk met à disposition un testeur fiable survitaminé, qui navigue de page en page, remplit des champs, revient en arrière ou valide des formulaires.

Le code de pilotage est élégant, simple à rédiger, à relire et permet même de gérer les SPA (Single Page Apps) ou la problématique du JavaScript chargé de manière asynchrone.

2. Installation

Pour commencer à utiliser Dusk avec Laravel Sail, il faut d’abord que le service selenium soit installé. Il fait partie des services installés par défaut lors de l’installation d’une nouvelle application Laravel mais peut être rajouté ultérieurement si besoin. Par contre, le package laravel/dusk n’est pas encore installé et doit être ajouté.

Commandes à exécuter pour l’ajout du service selenium

php artisan sail:add selenium  

Commandes à exécuter pour l’installation du package laravel/dusk

sail composer require --dev laravel/dusk 
 
sail artisan dusk:install  

Par défaut, Dusk se base sur les variables d’environnement du fichier .env. Pour éviter que Dusk exécute ses tests sur notre environnement local, nous devons lui spécifier ses propres variables d’environnement. Il faut faire une copie de notre fichier .env en respectant le nommage .env.dusk.{environment}. Ce qui donne pour nos tests en local : .env.dusk.local. Les variables d’environnement...