Écrire des tests unitaires avec PHPUnit, Partie 3 : Configuration XML
Dans les articles précédents de cette série, j’ai abordé les deux sujets suivants :
- Ecrire des tests unitaires avec PHPUnit, Partie 1: Le set-up. Un guide pour commencer à écrire des tests PHPUnit en utilisant un cache de base et en utilisant la méthode setUp du framework.
- Écrire des tests unitaires avec PHPUnit, partie 2 : le démontage. Un tutoriel sur la façon d’écrire des tests unitaires qui exploitent correctement les méthodes setUp et tearDown de PHPUnit.
Chacun des éléments ci-dessus est destiné à fournir une introduction sur la façon de commencer à écrire des tests unitaires très basiques. Les choses peuvent devenir plus complexes, surtout à mesure qu’une application ou un projet grandit (mais c’est toujours vrai, non ?).
Mais pour s’assurer que l’on est préparé pour cela, il y a un dernier composant des tests unitaires sur lequel je pense que nous devrions nous concentrer et c’est comprendre le fichier de configuration PHPUnit XML (que vous avez peut-être vu dans d’autres projets comme phpunit.xml).
Configuration XML de PHPUnit
Donc, dans cet article, je vais configurer un projet simple qui utilise PHPUnit, écrit quelques tests comme ceux que nous avons déjà vus et exploite un fichier de configuration pour automatiser les tests.
De plus, je vais faire ce que je peux pour expliquer au mieux les parties nécessaires du fichier de configuration afin que vous puissiez en inclure un dans votre prochain projet.
1 Écraser les fichiers
Avant de se lancer dans l’écriture de code testable, il est important de connaître les fichiers qui seront nécessaires pour faire fonctionner le processus.
Voici, plus ou moins, comment nous organisons les choses dès le début d’un projet :
- un répertoire pour les tests,
- le fichier phpunit.xml
Finalement, vous verrez également :
- les fichiers qui composent le projet,
- les tests qui vérifient lesdits fichiers.
À ce stade, cependant, examinons le fichier de configuration XML, puis essayons d’exécuter PHPUnit automatiquement sans aucun autre paramètre.
2 Les bases du fichier de configuration
Examinons d’abord le fichier de configuration de base :
<?xml version="1.0" encoding="UTF-8"?>
<!-- http://phpunit.de/manual/4.1/en/appendixes.configuration.html -->
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://schema.phpunit.de/4.1/phpunit.xsd"
bootstrap="./tests/bootstrap.php"
backupGlobals="false"
colors="true"
convertErrorsToExceptions="true"
convertNoticesToExceptions="true"
convertWarningsToExceptions="true"
>
<testsuites>
<testsuite name="AcmeTests">
<directory>./tests</directory>
</testsuite>
</testsuites>
<logging>
<log type="coverage-text" target="php://stdout" showUncoveredFiles="true"></log>
</logging>
</phpunit>
Comprenons maintenant ce que nous examinons exactement (autre que le simple XML).
- unité php. Le nœud parent fait le travail habituel de définition du schéma pour le fichier XML, mais il y a quelques autres composants qui nous concernent:
- backupGlobals. Ceci est en fait lié à une annotation que nous pouvons faire dans notre code source. Les variables globales sont quelque chose que nous devrions essayer d’éviter dans la programmation orientée objet, mais si vous choisissez d’en utiliser une ou avez besoin d’en utiliser une, cela indiquera à PHPUnit de gérer les valeurs que les variables globales maintiennent (et vous donnera la possibilité de restaurer leur). Je laisse généralement cela tel quel.
- amorcer. Ceci est facultatif, mais si vous choisissez d’inclure d’autres fichiers avec vos tests (comme apporter une bibliothèque moqueuse, une partie de WordPress ou une bibliothèque tierce), alors cela vous permettra de définir l’emplacement du script qui doit exécuter. La moquerie et l’introduction de WordPress sortent du cadre de cet article, mais c’est quelque chose que nous examinerons probablement à l’avenir car il est utile lors du test de plugins. Pour l’instant, j’inclurai un simple chargeur automatique qui ajoute essentiellement tous les fichiers à la racine du répertoire du projet. La source complète sera partagée plus tard dans cet article.
- couleurs. Si vous souhaitez que la console imprime un rapport de vos tests et le fasse en utilisant des couleurs (pour aider à identifier plus facilement les avertissements, les avis, les erreurs, etc.), définissez-le sur true.
- Ce qui suit sont toutes des valeurs booléennes. Je recommande de les définir sur true pour les rapports les plus agressifs possibles. De cette façon, vous ne vous contenterez pas de faire passer des avis ou des avertissements tout en vous souciant uniquement des erreurs. Il s’agit plus d’un exercice de qualité de code qu’autre chose.
- convertErrorsToExceptions
- convertNoticesToExceptions
- convertWarningsToExceptions
- Les suites de tests sont constituées de collections de tests. Étant donné qu’un projet donné peut avoir plusieurs tests, il est important de s’assurer que vous donnez à chaque suite un nom unique et que vous référencez le chemin d’accès approprié au groupe de tests. Pour notre exemple, nous n’aurons qu’une seule suite de tests et elle se trouve dans le répertoire tests.
- La journalisation est une fonctionnalité qui peut être aussi simple que d’imprimer des données dans la console ou d’utiliser une bibliothèque tierce (comme Clover) pour générer des rapports qui facilitent l’intégration continue. Comme je n’ai pas encore discuté de ce dernier dans aucun de mes articles précédents, nous allons nous en tenir à la console comme principale méthode de sortie. Ainsi, nous avons php ://stdout comme seule sortie de journalisation.
Cela dit, notre fichier XML contient tout ce dont PHPUnit a besoin pour fonctionner sans aucun autre paramètre.
N’oubliez pas, cependant, avant de passer au reste de cet article, je suppose que vous avez globalement installé PHPUnit sur votre système à l’aide de Composer. Si ce n’est pas le cas, consultez cet article car il vous fournira des instructions sur la façon de le faire.
Une fois cela fait, vous pouvez vérifier que PHPUnit est installé en saisissant la commande suivante dans votre terminal :
$ which phpunitEt vous devriez voir quelque chose comme ceci :
Si vous voyez quelque chose comme ci-dessus, vous pouvez exécuter PHPUnit n’importe où depuis votre système.
3 Le fichier d’amorçage
Avant d’aller plus loin, écrivons un fichier d’amorçage de base. Nous l’appellerons bootstrap.php et le déposerons dans notre répertoire de tests. Il comprendra les éléments suivants :
<?php
// This array has a single file but could whole the contents of an entire directory.
$files = [
dirname(__DIR__).'/AcmeCache.php',
];
foreach ($files as $file) {
if (file_exists($file)) {
require_once $file;
}
}
Il s’agit d’un simple "chargeur automatique" (que je l’appelle avec hésitation étant donné qu’il ne fait qu’itérer dans les fichiers et les exiger, mais cela fonctionne pour nos besoins).
À ce stade, mettons en place un test de base.
4 Un test de base qui échoue
Si vous lisez quelque chose sur le développement piloté par les tests, vous entendrez probablement parler du cycle de répétition rouge-vert. Il y a beaucoup à dire à ce sujet et je vous recommande de le lire, mais ce n’est pas le but de cet article.
Au lieu de cela, nous nous concentrons davantage sur l’écriture de tests qui correspondent à ce que nous devons faire, n’est-ce pas ? Cela dit, procédons comme suit :
- créez un répertoire à partir duquel vous allez avoir quelques fichiers PHP de base que nous testerons,
- à la racine du répertoire, créez également phpunit.xml et remplissez-le en utilisant le code partagé plus tôt dans ce post
- créer un répertoire de tests où nous placerons nos tests.
Maintenant, depuis le Terminal, changez de répertoire dans le répertoire du projet (ce qui fait certes défaut, pour l’instant) puis lancez simplement php unit :
$ phpunitEn supposant que tout est configuré correctement, vous devriez voir quelque chose comme ceci :
Puisque nous n’avons ni code ni tests, nous allons naturellement voir la sortie ci-dessus, n’est-ce pas ? Écrivons donc un seul test qui s’exécutera (et échouera) car il n’y a pas de code à tester.
Tout d’abord, dans le répertoire tests, créez un fichier appelé AcmeCacheTest.php. Et faisons quelque chose de simple comme instancier un objet cache que nous créerons éventuellement.
<?php
namespace AcmeTests;
use PHPUnitFrameworkTestCase;
use AcmeAcmeCache;
class AcmeCacheTest extends TestCase
{
private $cache;
public function setUp()
{
$this->cache = new AcmeCache();
}
public function testCacheExists()
{
$this->assertNotNull($this->cache);
}
}
Avant d’exécuter le test, notez que nous :
- Assurez-vous d’ utiliser PHPUnitFrameworkTestCase
- Et que notre classe étende TestCase
Cela fait partie de ce qui rend l’utilisation de PHPUnit si facile. Une fois cela fait, exécutez le code suivant à partir de la racine de votre projet :
$ phpunitAprès cela, vous devriez voir ce qui suit :
Notez que cela donnera un test d’échec et il vous indiquera où le problème a été trouvé, le fichier et la ligne.
Pour résoudre ce problème, nous devons écrire une classe :
<?php
namespace Acme;
class AcmeCache
{
private $duration;
public function __construct()
{
$this->duration = 43200;
}
public function setDuration(int $duration)
{
$this->duration = $duration;
}
public function getDuration(): int
{
return $this->duration;
}
}
4 Quelques tests de base et réussis
Le test de réussite de base (qui sera basé sur le code précédent) comprendra les éléments suivants :
- un fichier namespaced,
- représentera un simple cache,
- sera automatiquement chargé par PHPUnit en utilisant le fichier bootstrap.php partagé ci-dessus
- et aura une durée définie dans son constructeur avec un setter et un getter pour la valeur
Tout d’abord, testons que nous sommes capables de configurer la classe et qu’elle n’est pas nulle. C’est un peu une affirmation inutile puisque nous savons que nous aurons une classe correctement instanciée, mais cela nous plonge dans le rythme de l’écriture de tests :
<?php
namespace AcmeTests;
use PHPUnitFrameworkTestCase;
use AcmeAcmeCache;
class AcmeCacheTest extends TestCase
{
private $cache;
public function setUp()
{
$this->cache = new AcmeCache();
}
public function testCacheExists()
{
$this->assertNotNull($this->cache);
}
}
Et lancez le test :
Ensuite, vérifions que la valeur par défaut du cache est définie :
<?php
namespace AcmeTests;
use PHPUnitFrameworkTestCase;
use AcmeAcmeCache;
class AcmeCacheTest extends TestCase
{
private $cache;
public function setUp()
{
$this->cache = new AcmeCache();
}
public function testCacheExists()
{
$this->assertNotNull($this->cache);
}
public function testDefaultCacheValue()
{
$this->assertSame(43200, $this->cache->getDuration());
}
}
Comme pour l’étape précédente, exécutez les tests et vous devriez maintenant voir deux tests réussis :
Enfin, testons pour voir si nous sommes capables de changer la valeur avec succès :
<?php
namespace AcmeTests;
use PHPUnitFrameworkTestCase;
use AcmeAcmeCache;
class AcmeCacheTest extends TestCase
{
private $cache;
public function setUp()
{
$this->cache = new AcmeCache();
}
public function testCacheExists()
{
$this->assertNotNull($this->cache);
}
public function testDefaultCacheValue()
{
$this->assertSame(43200, $this->cache->getDuration());
}
public function testSetCustomDuration()
{
$duration = 4200;
$this->cache->setDuration($duration);
$this->assertSame($duration, $this->cache->getDuration());
}
}
Et les trois derniers tests de réussite :
Et voila:
- un Fichier XML PHPUnit,
- un simple bootstrap,
- une seule classe avec espace de noms,
- tests unitaires pour chaque méthode de la classe
Certes, c’est simple, mais cela pose les bases de bien plus que ce que beaucoup de gens font déjà avec leurs tests.
De plus, cela vous donne quelque chose sur quoi vous appuyer au fur et à mesure que vos côtelettes de test se renforcent.
Y a t-il plus? (Toujours raison?)
Enfin, si vous souhaitez vraiment vous plonger dans le fichier de configuration, vous pouvez lire l’ explication détaillée du manuel à ce sujet.
Notez, cependant, que tout ce qui est décrit ci-dessus vise à être ce dont vous avez besoin pour commencer à configurer votre propre fichier de configuration PHPUnit XML.