Écrire des tests unitaires avec PHPUnit, partie 1 : la configuration

Last updated Nov 26, 2022

Teneur

Tests unitaires avec PHPUnit, partie 1 : la configuration

Plus tôt ce mois-ci, nous avons commencé à envisager d’installer PHPUnit dans Visual Studio Code dans le but ultime d’apprendre à écrire des tests unitaires pour nos projets basés sur WordPress.

À cette fin, cet article suppose que vous avez lu les articles suivants et suppose que vous avez rattrapé une poignée d’articles précédents :

Et, bien sûr, installer PHPUnit dans Visual Studio Code comme indiqué ci-dessus. Une fois cela fait, nous serons prêts à continuer. Mais une chose à garder à l’esprit est qu’il s’agira d’un cours traditionnel ou complet d’écriture de tests unitaires.

Au lieu de cela, il s’agit d’écrire des tests unitaires pour les projets WordPress.

Tests unitaires avec PHPUnit, partie 1 : la configuration

Avant d’entrer trop dans les détails, je tiens à préciser qu’il ne s’agit pas tant d’un article sur le développement piloté par les tests, mais d’un article qui jette les bases de la compréhension de l’écriture de tests unitaires. Et puis, finalement, nous travaillerons à l’écriture de tests unitaires pour notre code.

Pour ceux d’entre vous qui ont déjà lu les tests unitaires, vous savez que l’écriture de tests unitaires est un sujet pour lequel il existe de nombreuses informations et cet article ne tentera pas de couvrir tout cela. Au lieu de cela, il va adopter une approche plus pragmatique pour écrire des tests unitaires sur des plugins basés sur WordPress, des applications Web, etc.

1 Rédaction de tests unitaires

Chaque fois que vous vous lancez dans l’écriture de tests unitaires pour la première fois, l’idée des méthodes setUp et tearDown vous sera présentée. Ceci est courant dans PHPUnit (comme avec d’autres frameworks de test). Il y a quelques choses à propos de ces deux méthodes particulières qui causent souvent des problèmes.

En bref, les gens traitent les fonctions comme suit :

setUp est comme le constructeur où vous instanciez votre classe, puis vous préparez tout ce dont vous avez besoin pour votre test, y compris l’objet à tester, les données nécessaires, etc.
tearDown est le destructeur où vous réinitialisez tout, puis vous débarrassez de vos objets. Ceci est généralement plus courant dans les langages compilés, mais il ne faut pas non plus le manquer dans PHPUnit.

Et même si je peux tout à fait comprendre cela, ce n’est pas toujours le cas. Je parle d’expérience ici aussi. Au lieu de cela, c’est de là que vient le test unitaire de la phrase réelle. Il s’agit de tester le code de code des unités et de le faire de manière claire et concise.

Alors, à quoi servent ces méthodes, de toute façon? Cela peut être une habitude particulièrement difficile à briser ou même un modèle conceptuel à briser lorsque vous vous lancez pour la première fois dans le processus. À cette fin, je souhaite examiner le but de chaque méthode, puis comment l’aborder lorsque vous travaillez avec des projets basés sur WordPress.

Et, comme d’habitude, je m’efforcerai de garder cela aussi simple et pragmatique que possible. Je suis beaucoup moins intéressé par la théorie derrière certaines choses que par la façon dont cela peut bien servir à la fois mon entreprise et mes projets. (Ce n’est pas pour écarter la théorie, bien sûr, mais il y a un temps pas un endroit pour ça et ce blog n’est pas ça.)

2 La fonction de configuration

Même si je commence par une brève discussion sur la méthode setUp, il est important de garder à l’esprit que sa fonction sœur (comme certains la considèrent) n’est pas toujours nécessaire.

Par exemple, si vous écrivez du code où tout ce que vous faites est d’instancier un objet ou un ensemble d’objets, la méthode tearDown peut ne pas être nécessaire. Je reviendrai plus en détail à ce sujet dans la section suivante.

Cela dit, disons que vous avez une classe responsable de l’exécution d’un peu de logique de domaine. Rappelez-vous, pour les besoins de cet article, nous ne sommes pas concernés par le code qui fera des choses que WordPress fait naturellement et qui a déjà son propre ensemble de tests.

Par là, je veux dire que nous sommes concernés par le code qui fonctionne spécifiquement dans un domaine problématique. Par exemple, nous sommes peut-être concernés par l’écriture d’une classe qui met en cache des données dans la base de données. L’une des informations responsables de la mise en cache des informations est la durée pendant laquelle les données doivent être mises en cache. Ainsi, un candidat au test unitaire ferait en sorte que nous soyons capables de définir et de modifier la durée, n’est-ce pas ?

Certes, ces données sont peut-être codées en dur, mais à titre d’exemple, supposons le contraire. Cela implique ce qui suit :

Nous avons une classe qui nous sert de cache,
La classe conserve une donnée d’instance pendant combien de temps le cache doit être défini,
Le temps de cache peut être défini à partir de classes tierces,
L’heure du cache peut être lue à partir de classes tierces.

Cela signifie qu’un test unitaire comprendrait :

Mise en place de la classe,
Définir une valeur,
Affirmer que la valeur qui a été définie est comme prévu,,
Modification de la valeur,
L’affirmation de la valeur modifiée a été mise à jour.

Ainsi, la classe de base peut ressembler à ceci (toute la documentation étant laissée de côté dans le but de garder le code aussi concis que possible) :

Notez que, par défaut, nous avons le temps de cache fixé à 12 heures (en secondes). La classe prend également en charge la possibilité de modifier et de lire la durée.

Cela signifie que nous pouvons écrire des tests qui testent :

si la valeur initiale correspond à ce qui était attendu,
si la nouvelle valeur est celle qui était attendue (et qu’elle écrase la valeur initiale)

L’une des choses que je voudrais souligner dans le code ci-dessus est que vous pouvez lire que chaque test doit avoir une seule assertion alors que testNewDuration a clairement deux assertions.

J’ai tendance à prendre l’idée d’une affirmation par test comme une règle empirique. Par exemple, dans ce cas, je veux affirmer que la valeur initiale est écrasée ou stockée nulle part et que la nouvelle valeur est stockée.

Ce n’est peut-être pas toujours le cas, vous devrez donc peut-être traiter ce type de situation avec précaution.

Comme vous pouvez le voir, cela n’a rien à voir avec WordPress ; cependant, cela a à voir avec la logique de test liée spécifiquement au domaine concerné. A savoir, la durée du cache. Et c’est le cœur des tests unitaires: tester le comportement logique des unités de code pour s’assurer que tout fonctionne comme prévu.

Et selon le moment où vous écrivez ce code, vous pouvez avoir des tests qui échouent. Cela peut finalement aider à la conception de classe, mais c’est un autre sujet et pas celui qui fait partie de ce post.

Exécution des tests

Une fois les tests écrits, il est important de pouvoir les exécuter pour voir s’ils réussissent, s’ils échouent, ce qui réussit et ce qui échoue. Mais nous n’avons pas encore fini. Je veux fournir un aperçu complet des tests unitaires dans le contexte de WordPress et cela revient à discuter de ce que WordPress fournit, de ce qu’il ne fait pas, de certaines idées fausses et de la façon d’exécuter ces tests dans le terminal ou dans Visual Studio Code.

Dans le prochain article de cette série, nous allons examiner la fonction tearDown et comment (et quand) l’utiliser, quand c’est nécessaire, quand ce n’est pas le cas, puis nous allons examiner un peu l’unité tests dans WordPress en général.

En fin de compte, nous nous efforçons d’obtenir une image complète de la façon de procéder et de la manière de le faire correctement. Mais il est important de jeter les bases de cela et de le faire sur plusieurs postes est plus facile que sur un seul poste monolithique.

Donc, examiner tearDown(), son utilisation et comment exécuter des tests à partir de la ligne de commande sera le sujet du prochain article de cette série.

Source d’enregistrement: tommcfarlin.com