Share
Nous avons examiné les tests unitaires pour le développement WordPress. À l'aide d'exemples pratiques, nous avons examiné à quoi ressemblait le test unitaire pour les plugins et les thèmes; cependant, nous n'avons pas vraiment parlé de la théorie derrière les tests unitaires.
C'est-à-dire que nous n'avons pas examiné de manière approfondie ce que c'est, pourquoi c'est bénéfique et comment nous pouvons l'intégrer dans notre flux de travail. Dans la prochaine série d'articles, nous définirons le test unitaire, couvrirons ses principaux avantages, expliquerons pourquoi nous devrions nous en préoccuper, ainsi que certaines des ressources dont nous disposons pour notre travail..
Bien qu'il n'y ait pas de code à travailler pour ce tutoriel particulier, il devrait fournir une base solide sur laquelle s'appuie l'application pratique des articles précédents.
Avant de plonger dans l'article, je pense qu'il est important d'examiner les raisons pour lesquelles on devrait se donner la peine de tester des thèmes et des plugins..
Jusqu'à récemment, WordPress était principalement considéré comme une plateforme de blogs et un système de gestion de contenu. Il fait tous les deux très Bien, mais à mesure que les développeurs découvrent sa riche API, il est de plus en plus courant de créer certains types d’applications utilisant WordPress comme plate-forme sous-jacente..
De plus, les thèmes sont plus que des skins pour un site Web - ils sont plus qu'une feuille de style et quelques fichiers de gabarit pour l'affichage de données. En fait, maintenant, peut-être plus que jamais, des équipes entières consacrent du temps (et vivent même de la création) à la production de thèmes pour WordPress. Ne laissez donc pas le mot "thème" vous égarer - les thèmes sont comme des applications pour WordPress. Ils ajoutent des fonctionnalités, pré-traitent et post-traitent les données et introduisent souvent des fonctionnalités importantes dans WordPress, bien au-delà du simple fait de donner un coup de jeune à votre site Web..
Enfin, les plugins sont presque plus naturels que les thèmes. Considérez-le de cette façon: les plugins étendent le noyau de WordPress et fonctionnent souvent indépendamment des thèmes. Au lieu de cela, ils ajoutent de nouvelles fonctionnalités au cœur de WordPress dont tous les thèmes peuvent bénéficier.
Je dis tout cela pour donner une idée de la raison pour laquelle les tests unitaires - comme nous sommes sur le point de le découvrir - peuvent être rentables à maintes reprises, car ils sont utilisés dans le contexte de thèmes et de plugins plus complexes..
Nous en avons brièvement parlé dans le premier article de la série. Je ne veux pas donner un aperçu complet de ce qui a déjà été écrit, alors je vais résumer les points ici:
Mais c'est juste gratter la surface.
Pour vraiment comprendre les unités de votre thème ou de votre plugin, vous devez penser à ce qui compose un thème. Typiquement, c'est une combinaison de:
Bien qu'il existe des frameworks de tests unitaires spécifiques à JavaScript, nous allons nous concentrer davantage sur l'aspect PHP du développement WordPress. Après tout, sans la fonctionnalité côté serveur, il y aurait très peu de fonctionnalités uniques introduites dans WordPress..
Cela dit, il existe plusieurs façons de définir une unité, mais je parierais que la plupart des gens définissent une unité en tant que fonction. La plupart du temps, c'est exact, mais cela ne signifie pas que nos fonctions sont les unités les plus optimales à tester. Par exemple, les fonctions consistent souvent en plusieurs blocs - peut-être des boucles, peut-être des conditions, ou peut-être des appels à d'autres fonctions.
Quoi qu’il en soit, les méthodes contiennent souvent des unités de fonctionnalité plus petites..
Alors, est-il vraiment exact de dire que le test unitaire implique le test de chaque fonction constituant un thème? Pas vraiment. Puisqu'un seul bloc de code - ou, dans certains cas, une seule instruction - est responsable de la réalisation d'une tâche spécifique, celles-ci constituerait de véritables unités de code.
Et si nous sommes supposés écrire des tests unitaires, comment pouvons-nous écrire des tests pour les unités existantes dans nos fonctions?
Rappelez-vous qu'au début de la série, j'ai dit:
C'est là que se produit l'un des plus grands changements dans l'écriture de code testable par unités: vous divisez des unités de fonctionnalités en une plus petite pièce atomique possible. Bien sûr, cela entraîne souvent un nombre élevé de très petites fonctions, mais est-ce une mauvaise chose?
Ce faisant, chaque fonction a vraiment un seul but. Et en supposant que votre fonction ne fasse qu'une seule chose, il n’existe que de nombreuses façons de la nommer, ce qui peut générer un code beaucoup plus lisible..
Bien sûr, il y a un compromis: vous introduisez peut-être quelques lignes de code supplémentaires lors de l'écriture de ces fonctions supplémentaires, mais lorsque vous travaillez sur un produit avec une équipe composée de plusieurs personnes qui sera utilisé par des milliers de clients, vous devez vous demander si le code supplémentaire vaut la qualité que vous pouvez obtenir en testant correctement votre travail. Bien fait, ton équipe devrait être capable de suivre plus facilement la logique du code et le produit aura un niveau de qualité souvent difficile à atteindre sans écrire des tests unitaires.
Un élément clé à reconnaître à propos des tests unitaires est qu’ils ne sont pas dépendants les uns des autres. Un seul test unitaire devrait tester une et une seule chose. De plus, cela signifie qu'un test unitaire ne devrait inclure qu'une seule affirmation (mais il y a des exceptions qui sont démontrées ici).
Rappelez-vous: le but d'un test unitaire est d'évaluer la qualité d'une seule unité de code. Certaines unités accepteront des arguments, d'autres non, d'autres renverront des valeurs. Quel que soit le cas, votre test unitaire doit évaluer tous les cas. Une seule unité de code aura rarement un seul test.
Au lieu de cela, je dirais qu’une bonne règle générale est que le nombre de tests associés à une unité de code varie de façon exponentielle en fonction du nombre d’entrées acceptées..
Par exemple:
Avoir un sens? L'essentiel est que vous aurez beaucoup plus de tests qu'il n'y a d'unités. il n'y a pas de ratio 1: 1.
Enfin, lorsque vous effectuez des tests unitaires, vous verrez souvent le mot "suite de tests" ou "suite" utilisé lors des discussions sur les tests. Cela peut varier en fonction du contexte dans lequel se déroule le test; cependant, lorsque vous travaillez avec WordPress, cela fait généralement référence à une collection de tests unitaires.
Supposons donc que vous disposiez d'un fichier chargé de tester toutes les fonctionnalités relatives à la rédaction et à la publication d'un message. Ce fichier serait la suite de tests pour les messages. Assez facile, non? Il est important de comprendre cette terminologie si vous rencontrez cela dans une lecture ultérieure, car elle peut légèrement différer si vous travaillez dans, par exemple, Rails ou .NET..
Enfin, les tests unitaires ne sont pas une nouvelle méthodologie et ne sont pas strictement limités à PHP. En fait, les tests unitaires (ou le développement piloté par les tests dans son ensemble) existent depuis plus de dix ans..
Vous pouvez trouver des frameworks de tests unitaires pour Java, .NET, Rails, PHPUnit (évidemment), etc..
Mais son adoption a été mitigée - certaines personnes vivent et meurent, d'autres la détestent, et certains d'entre nous cherchent à le faire mais doivent trouver un équilibre entre l'application pratique consistant à l'inclure dans un projet existant et à comprendre la quantité de refactoring cela peut nécessiter.
En ce qui concerne la théorie, nous commençons tout juste.
Dans le prochain article, nous examinerons plus particulièrement les principaux avantages des tests unitaires et leurs avantages pour notre développement basé sur WordPress. Nous examinerons également les avantages des tests unitaires pour l'architecture, la conception et la documentation..
Bien sûr, les tests unitaires ne sont pas sans inconvénients, nous allons donc les examiner.
Accentsconagua