Écrire des tests unitaires avec PHPUnit, partie 2 : le démontage
À la fin du mois dernier, j’ai commencé à parler de l’écriture de tests unitaires dans PHPUnit pour du code basé sur WordPress. Cela incluait principalement l’idée de configurer PHPUnit, la fonction setUp et d’écrire des tests de base.
Cela n’a cependant pas discuté de ce que je sais de la fonction tearDown qui est toujours une caractéristique importante de l’écriture à l’aide de tests. De plus, il existe également deux façons d’envisager l’écriture de tests pour les projets WordPress.
À savoir:
- écrire des tests spécifiquement pour les plugins et les fonctionnalités de la couche application,
- exécuter des tests unitaires sur l’application WordPress.
Avant d’aller de l’avant avec ce post particulier, cependant, je vous recommande de rattraper ce que j’ai couvert jusqu’à présent. Cela inclut les messages suivants :
- Un environnement de développement WordPress (à l’aide d’un gestionnaire de packages)
- Un IDE pour le développement WordPress
- Utilisation des paramètres utilisateur dans Visual Studio Code
- Écrire des tests unitaires avec PHPUnit, partie 1 : la configuration
Une fois que vous avez fait cela, revenez à ce post et continuons à discuter de la fonction tearDown et à quoi ressemblent réellement les tests unitaires dans le contexte de WordPress.
Tests unitaires avec PHPUnit, partie 2 : le démontage
Avant d’aller plus loin, souvenez-vous que les développeurs traitent souvent la fonction setUp comme un constructeur et la fonction tearDown comme un destructeur ; cependant, rappelez-vous que ce dernier n’est pas toujours nécessaire.
Voici une bonne règle à retenir :
- Tout ce dont une fonction de test a besoin appellera la fonction setUp afin que les classes nécessaires soient nécessaires.
- La fonction tearDown n’est pas toujours nécessaire puisque la fonction setUp peut réinitialiser une classe.
Alors qu’est-ce que cela signifie pour la fonction tearDown si elle ne réinitialise pas les données créées pendant la fonction setUp ?
1 La fonction de démontage
Le meilleur conseil que je puisse donner concernant la fonction tearDown est qu’elle doit être utilisée si quelque chose est configuré pendant l’un des tests qui reste.
Cela peut être quelque chose qui est écrit dans une base de données, quelque chose qui est écrit dans un journal ou, plus généralement, quelque chose qui est écrit sur le disque dur.
Ainsi, si un test écrit un enregistrement ou un fichier, la méthode tearDown s’exécutera après un test et devrait supprimer tout test enregistré sur le lecteur qui ne fait pas partie du test mais qui n’est pas nécessaire en permanence pour le prochain test ou qui doit être nettoyé après lui-même.
Donc, dans un sens, c’est comme un destructeur, mais si vous n’avez jamais utilisé un langage qui a un destructeur, cette nomenclature semble non pertinente ou n’a pas de sens.
Un destructeur est une fonction membre spéciale qui est appelée lorsque la durée de vie d’un objet se termine. Le but du destructeur est de libérer les ressources que l’objet a pu acquérir au cours de sa vie.
Ainsi, il vaut peut-être mieux penser simplement à la fonction comme un moyen de nettoyer après un test (et non dans le sens de définir une variable égale à null puisque la fonction setUp peut le faire).
2 tests unitaires pour les projets WordPress
Lors de l’écriture de tests unitaires pour des projets WordPress, nous devons nous assurer que nous sommes clairs sur le type de tests unitaires dont nous parlons.
Par exemple, ce que j’appellerai les tests unitaires classiques ou standard suivent la méthodologie de «développement piloté par les tests» dont je parlerai dans un instant. D’autre part, WordPress a son propre ensemble de tests unitaires pour les thèmes et autres dont je parlerai également un peu plus tard dans cet article.
Mais pour cette section, j’ai pensé qu’il pourrait être utile de parler un peu du premier plutôt que du second afin que vous puissiez voir comment cela pourrait fonctionner.
Dans l’exemple ci-dessous, j’écris des tests sur un plug-in chargé de communiquer avec une API tierce. Ce plugin particulier nécessite un nom d’utilisateur et un mot de passe ou une API et nous voulons nous assurer que, pour les besoins de cet article, il récupère correctement une erreur chaque fois que le test est exécuté.
Notez qu’en parcourant ce code, vous allez me voir parler un peu de réflexion. Je vais bientôt faire un article complet sur PHP Reflection afin de faire la lumière là-dessus.
Pour le code ci-dessous, cependant, supposons que c’est un moyen d’accéder à des propriétés qui sont autrement marquées comme privées.
Rappel du dernier article de cette série, nous avons eu un premier test qui ressemblait à ceci :
Remarquez, cependant, dans ce test, il n’y a pas de fonction tearDown qui a du sens, n’est-ce pas ? Après tout, rien n’est écrit dans une base de données ou dans un fichier.
Mais disons que nous voulons introduire un cas de test qui va avoir un nom de fichier, un contenu et qui va écrire le contenu dans le fichier. Dans ce cas, il s’agira de données statiques, mais cela pourrait techniquement être tout ce qui est écrit sur le disque.
1 Configuration du test
Tout d’abord, nous voulons configurer le test en définissant le nom du fichier, le contenu du fichier et en préparant les propriétés.
Assez facile, non ?
2 Écrire et lire des données
Ensuite, nous voulons écrire les données, lire les données et affirmer que le contenu est le même.
À ce stade, si vous exécutez le test (que je n’ai pas encore couvert techniquement sur la façon de le faire), vous remarquerez que testFile.txt réside toujours sur votre système.
3 Utiliser le démontage
Enfin, nous devons travailler avec la méthode tearDown pour nous assurer que le fichier est supprimé à la fin du test unitaire. Voici à quoi cela peut ressembler si vous avez implémenté votre code comme ce que vous voyez ci-dessus.
Notez que dans la méthode tearDown, je vérifie d’abord si un file_exists. En effet, si vous essayez simplement de dissocier un fichier qui n’est pas présent, vous obtiendrez une erreur lors de l’exécution de vos tests, car si tearDown est présent, il essaiera de supprimer quelque chose après chaque fonction de test. Et si le fichier n’existe pas, alors il n’y a rien à supprimer, et il en résultera donc un problème.
Donc, pour tenter d’écrire du code de manière défensive, je pense qu’il est responsable de vérifier si le fichier existe avant d’essayer de le supprimer.
3 Ordre des opérations
En ce qui concerne les tests unitaires purs, vous allez normalement lire ceci en termes de développement piloté par les tests. C’est un grand sujet en soi; cependant, il convient de le mentionner ici si vous choisissez de le rechercher plus avant et même de l’implémenter dans vos efforts de développement.
L’idée générale derrière cette approche est souvent appelée "répétition rouge-vert". Et je ne le nie pas, il y a quelque chose dans cette approche. À savoir, cela vous permet, en tant que développeur, d’écrire du code tel que vous vous attendez à ce qu’il fonctionne avant d’écrire réellement le code.
La psychologie sous-jacente est la suivante : si vous savez comment fonctionne le code, vous êtes plus susceptible d’écrire des tests qui réussissent ; tandis que si vous écrivez des tests sur la façon dont le code doit fonctionner, vous devriez écrire un meilleur code.
Malheureusement, nous n’avons pas toujours ce luxe. Mais cela ne signifie pas que nous devrions jeter le proverbial bébé avec l’eau. Au lieu de cela, je suis d’avis que vous devriez écrire des tests quand vous le pouvez et écrire le code ensuite ; sinon, écrivez vos tests après votre code.
En fin de compte, avoir des tests en place malgré tout vaudra mieux que pas de tests du tout.
4 Test avec WordPress
En ce qui concerne les tests unitaires dans WordPress, vous êtes probablement tombé sur certaines choses. Parfois, le contenu est un terme impropre ou peut même être trompeur en termes de "tests unitaires dans WordPress".
Par exemple, il y a deux choses à noter :
- Le test unitaire thématique. Cet ensemble particulier de contenu est destiné à aider les développeurs de thèmes à tester tous les cas majeurs et mineurs pour leurs thèmes. Il n’y a pas d’outils automatisés, par exemple, que vous utiliseriez comme dans ce dont nous avons discuté ci-dessus.
- Tests automatisés. WordPress est livré avec son propre ensemble de tests unitaires afin que nous n’ayons pas à écrire de tests sur la plupart des fonctionnalités de WordPress (comme si les fonctions API fonctionnent ou non comme prévu). Cela nous permet de nous concentrer sur l’écriture de tests unitaires pour notre propre logique de domaine.
- Tests unitaires des plugins. Si vous avez utilisé WP-CLI (ou si vous y êtes intéressé), vous avez probablement lu cette page ou même utilisé cet outil. C’est utile, mais cela cible également des aspects spécifiques du test des plugins WordPress.
Tout ce qui précède est une information utile, et je ne dis pas qu’il faut l’ignorer. Au lieu de cela, il devrait être couplé avec le reste des informations utilisées tout au long de cet article.
Exécution de tests unitaires
Dans le prochain article, je vous expliquerai tout ce que vous devez savoir pour configurer un fichier XML qui informera PHPUnit de l’emplacement des tests et de la manière de les exécuter.
Pour l’instant, cependant, passez en revue le code contenu dans cet article et préparez-vous à en tirer parti dans le prochain article de cette série.