Share
Dans les deux premiers articles de cette série, nous avons examiné en détail ce que sont les tests unitaires et comment l’appliquer dans le contexte du développement de plugins. Bien sûr, WordPress ne se limite pas à écrire des plugins, n'est-ce pas? Une partie importante d’un travail de développeur WordPress - pour certains, c’est la plus partie importante - est le développement de thème.
Dans cet article, nous allons donc examiner comment développer des thèmes testables. Plus précisément, nous allons voir en quoi les thèmes sont différents des plugins, puis nous allons écrire un thème extrêmement simple qui sera utilisé pour illustrer les principes du test unitaire et qui pourra être appliqué dans les développements futurs..
Avant de commencer à créer un thème ou à réviser un code, il est important de comprendre la différence de développement de thèmes et de plugins. Tout d'abord, les plugins peuvent être écrits de deux manières:
Les deux méthodes font la même chose: elles utilisent un ensemble de fonctions et de filtres pour introduire de nouvelles fonctionnalités dans WordPress. La principale différence est la manière dont les fonctions sont encapsulées.
Mais quand il s’agit de développer un thème, il n’ya vraiment qu’une façon de développer un thème: utiliser un ensemble de fonctions définies dans functions.php. Ceci présente les deux défis suivants pour l'écriture de tests unitaires pour les thèmes:
Parce que les bons thèmes utilisent une collection de filtres et d’actions, nous allons créer un thème qui respecte ces meilleures pratiques et parce que cet article met l’accent sur les thèmes de tests unitaires. Par conséquent, l’accent sera mis sur la rédaction des tests plutôt que sur créer un thème attrayant et très fonctionnel.
Avant de coder, initialisons le répertoire de notre projet. Nous devons configurer le squelette du thème afin que, dans votre répertoire de thèmes WordPress, créez un nouveau répertoire pour le thème. Le mien s'appelle Thème de base. Ajoutez les fichiers suivants (nous les remplirons plus tard):
Allons de l'avant et remplaçons la feuille de style afin que WordPress reconnaisse le thème et nous permette de l'activer à partir du tableau de bord. Pour ce faire, ajoutez le code suivant:
/ * Nom du thème: Thème de base URI du thème: TODO Version: 1.0 Description: Un thème de base utilisé pour montrer comment écrire des tests unitaires pour les thèmes. Auteur: Tom McFarlin Auteur URI: http://tommcfarlin.com Licence: GNU General Public License v2.0 Licence URI: http://www.gnu.org/licenses/gpl-2.0.html * /
Pour être complet, allez-y et ajoutez les balises PHP d'ouverture et de fermeture au début et à la fin de votre fichier de fonctions. Cela garantira que nous avons préparé le terrain lorsque nous commencerons à écrire des fonctions de thème plus tard dans cet article..
Et ajoutez un nouveau répertoire appelé tests. Ici, nous aurons besoin de placer les tests WordPress.
Plus tôt dans cette série, j’avais fourni un lien vers les tests WordPress situés sur GitHub. Bien que ces tests conviennent à l'utilisation, les tests WordPress les plus récents et maintenus par Automattic se trouvent dans ce référentiel Subversion.
Si vous êtes un développeur expérimenté, je vous recommande de vérifier ces tests. Toutefois, si vous commencez tout juste à utiliser les tests unitaires, pas de problème! Je fournis tout le code source, y compris les tests WordPress, dans un référentiel GitHub que vous pourrez télécharger, référencer et utiliser pour vos propres projets..
Une fois les tests installés, le répertoire de votre thème devrait ressembler à ceci:
Comme PHPUnit doit être exécuté à partir de la ligne de commande, vous devez ouvrir une session de terminal (ou une invite de commande), accédez au répertoire suivant. tests répertoire, et vous devriez pouvoir les exécuter en utilisant la commande suivante (à titre d'exemple):
phpunit tests / test_user_capabilities.php
Votre terminal devrait alors sortir quelque chose comme ceci:
La tête haute: Si vous ne parvenez pas à exécuter les tests, veuillez vous reporter au premier article de la série pour vérifier votre configuration. De plus, votre kilométrage peut varier en fonction de votre système d'exploitation, de votre serveur Web et de la configuration de votre ordinateur. Si vous finissez par avoir à faire quelque chose de différent, partagez vos notes dans les commentaires pour aider les autres.. À ce stade, activons le thème dans le tableau de bord. Le thème doit être activé (sinon, assurez-vous de ne pas avoir de caractères parasites dans vos fichiers modèles). Si vous essayez de voir le thème, il va naturellement afficher un écran blanc.
Avant d’écrire des tests, allons de l'avant et peuplons nos fichiers de modèles avec un peu de contenu afin que nous puissions avoir quelque chose montrer sur le frontend.
Dans header.php, ajoutez le code suivant:
<?php wp_title("); ?> >C'est l'en-tête.
Dans index.php, ajoutez le code suivant:
C'est le contenu.
Et en footer.php, ajoutez le code suivant:
C'est le pied de page.
C'est simple, je le sais, mais cela nous donnera juste assez pour travailler avec chaque fois que nous commençons à écrire des tests. Enregistrez votre travail, passez en revue le thème dans le navigateur et vous devriez voir ceci:
Dans ton tests répertoire, créez un fichier appelé test_basic_theme.php et stub le fichier pour ressembler à ceci:
Accentsconagua
// Inclut les fonctions du thème include_once ('… /functions.php'); La classe Test_Basic_Theme étend WP_UnitTestCase // end class Ci-dessus, nous définissons une classe qui sera utilisée pour emballer tous les tests unitaires de notre thème..
Premièrement, définissons le installer méthode. le installer La méthode est une fonction fournie par le framework de test WordPress et nous pouvons l’utiliser pour lancer certaines fonctions avant l’exécution des tests. Par exemple, lorsque les tests WordPress sont exécutés, ils s’appliquent au thème par défaut, à savoir Twenty Eleven. Dans notre cas, nous voulons exécuter les tests sur notre propre thème.
Pour ce faire, nous devrons dire à WordPress de changer de thème avant d'exécuter le reste de nos tests. Comme cela doit être fait avant que les tests ne soient exécutés, il faut le définir dans installer méthode. Avoir du sens?
Alors écrivons notre installer méthode:
fonction setUp () parent :: setUp (); switch_theme ('Thème de base', 'Thème de base'); // fin de la configuration Encore une fois, exécutons nos tests. Nous pouvons le faire en exécutant la même commande que lors de la configuration initiale du test:
phpunit tests / test_basic_theme.php
Si vous avez tout fait correctement, vous devriez réellement voir un échec lors de l'exécution du test:
Le message d'erreur est clair, cependant: "Aucun test trouvé dans la classe "Test_Basic_Theme"". Alors atténuons cela et écrivons le premier test pour le thème. Cela peut être quelque chose d'extraordinairement simple, mais souvenez-vous du post précédent que nous ne voulons pas tester juste le chemin optimal, mais aussi le chemin de la défaillance.
En tant que tel, nous devons vérifier que le thème de base est actif et que Twenty Eleven n'est pas actif. Pour ce faire, nous utiliserons la méthode assertTrue et la méthode assertFalse et nous le ferons dans le contexte de deux fonctions. Regardez le code ci-dessous et mettez à jour votre fichier de test en conséquence:
function testActiveTheme () $ this-> assertTrue ('Thème de base' == get_current_theme ()); // fin à la fonction testThemeInitialization testInactiveTheme () $ this-> assertFalse ('Twenty Eleven' == get_current_theme ()); // termine testInactiveTheme Encore une fois, exécutez les tests et vous devriez les voir passer au vert. Bonne droite?
Ceci est une fonctionnalité relativement simple, considérons donc quelques fonctions avancées que notre thème pourrait avoir.
Par défaut, Basic Theme n'inclut pas jQuery. Nous allons donc l'inclure dans notre thème. Si vous vous rappelez des publications précédentes, la méthodologie de test unitaire appropriée est la suivante:
Alors, faisons exactement ceci pour jQuery.
Premièrement, nous devons écrire un test pour déterminer si jQuery est chargé. Nous utiliserons la fonction WordPress wp_script_is. Puisque le thème traverse le cycle de vie d'une page dans un navigateur, nous devons indiquer manuellement à WordPress de charger jQuery à l'aide de la fonction do_action..
fonction testjQueryIsLoaded () $ this-> assertFalse (wp_script_is ('jquery')); do_action ('wp_enqueue_scripts'); $ this-> assertTrue (wp_script_is ('jquery')); // end testjQueryIsLoaded Avant d'aller plus loin, il y a quelque chose d'important à noter ici: je n'aime pas placer plusieurs assertions dans une seule fonction, car je pense que chaque fonction devrait servir à tester un seul objectif; Cependant, il y a des exceptions. Ici, nous devons nous assurer que jQuery n'est pas chargé avant d'appeler do_action.
Quoi qu'il en soit, lancez le test et ça va échouer. Nous devons donc ajouter le code à functions.php cela fera en sorte que jQuery soit ajouté à notre thème. Pour ce faire, incluez la fonction suivante dans votre fichier de fonctions:
function basic_add_jquery () wp_enqueue_script ('jquery'); // end basic_remove_jquery add_action ('wp_enqueue_scripts', 'basic_add_jquery'); Enfin, lancez le test et il devrait être vert. Assez facile, n'est-ce pas?
Disons que nous voulons inclure une méta description par défaut sur la page d'accueil. Dans le cas le plus simple, ce ne sera rien de plus que la description du blog. Par conséquent, en suivant la méthodologie décrite ci-dessus, introduisons une fonction pour vérifier que la chaîne de méta-description ajoutée à l'élément head correspond à ce que nous attendons:
fonction testBasicMetaDescription () $ meta_description = ''; $ this-> expectOutputString ($ meta_description, basic_meta_description ()); // fin de testBasicMetaDescription
Exécutez-le - ça va échouer. Notez que je n'utilise pas le standard affirmer vrai, affirmer fonctions - il y aura plus de détails à ce sujet dans un instant. Maintenant, introduisons la fonction suivante dans functions.php:
fonction basic_meta_description () echo ''; // end basic_meta_description add_action ('wp_head', 'basic_meta_description'); Notez que cette fonction s’accroche au wp_head action. Pour écrire la méta-description dans l'élément head, il faut écho la ficelle plutôt que revenir la ficelle.
Maintenant, notez que dans le test ci-dessus, nous utilisons expectOutputString. Ceci est utile lorsque nous devons évaluer une fonction qui écho une ficelle (plutôt que résultats un string). Depuis le wp_head Si l'action retourne une quantité importante de données (c'est-à-dire l'élément head en entier), il suffit en réalité d'évaluer la méta-description renvoyée. Et c'est pourquoi plutôt que d'appeler do_action ('wp_head'), J'appelle simplement la fonction elle-même et évalue la sortie par rapport à ce que j'attends.
Encore une fois, lancez PHPUnit et vos tests doivent tous réussir.
De toute évidence, nous n'avons fait qu'effleurer ce que les tests unitaires peuvent faire pour le développement de nos thèmes. Beaucoup de choses peuvent encore être testées - nous n'avons même pas essayé de tester The Loop, différentes façons d'évaluer les formats de publication, ni même d'examiner les commentaires..
Rappelez-vous ceci est un guide du débutant et les trois articles couvrent beaucoup de terrain.
Quoi qu’il en soit, les principes sont les mêmes: il suffit de s’assurer que vous exécutez par programme la fonction ou l’action appropriée et d’en évaluer le résultat dans les cas prévus et inattendus..
Enfin, vous pouvez trouver le projet entier ainsi que les fonctions documentées dans ce référentiel GitHub..
Voici un résumé des ressources utilisées dans cet article:
affirmer vraiaffirmerwp_script_isdo_actionwp_headexpectOutputString