Comment commencer à tester votre code WordPress avec le framework de test PHP Pest – WP Tavern

Nous pouvons tous convenir que WordPress a parcouru un long chemin depuis ses débuts et qu’il est devenu bien plus qu’un logiciel de blog.

À la base, il s’agit toujours d’un système de gestion de contenu (CMS), mais avec plus de 59 000 plugins dans le wordpress.org répertoire, vous pouvez le personnaliser pour qu’il soit beaucoup plus.

La raison de sa popularité est sa faible barrière à l’entrée pour les créateurs de contenu et les développeurs. Parfois, cela a un coût. Ce n’est un secret pour personne que WordPress a mauvaise réputation en matière de développement. Il a beaucoup de bagages hérités et de règles absolues qui empêchent tout changement de rupture de compatibilité descendante en ce qui concerne le code PHP (Gutenberg est une autre histoire que je n’aborderai pas).

Ce code PHP hérité est souvent utilisé par les développeurs qui commencent à entrer dans le monde de la programmation, et le problème est qu’ils peuvent apprendre de mauvais modèles de programmation. Cela signifie à son tour qu’ils réutiliseront le code mal écrit, augmentant ainsi la quantité de mauvais code dans le monde.

C’est là que WordPress tire sa mauvaise réputation dans la communauté des développeurs.

Briser le cycle

Alors, comment pouvons-nous briser ce cycle de mauvais code ? En enseignant aux nouveaux développeurs comment écrire un bon code. Un exemple d’enseignement aux nouveaux développeurs (mais aussi aux anciens qui s’accrochent encore à la façon de faire « WordPress ») consiste à écrire des didacticiels.

Une autre façon consiste à les encourager à utiliser des outils qui peuvent les aider à écrire un meilleur code.

Je suis actuellement impliqué dans le travail qui vise à sortir la nouvelle version du Normes de codage WordPressun ensemble de règles utilisées pour la PHP_CodeSniffer outil qui vous permettra de savoir si votre code présente des problèmes potentiels (sécurité, bonnes pratiques, style de code).

Un autre outil que j’ai récemment développé est un emballer qui aidera les développeurs à mettre en place des tests d’intégration WordPress qui utilisent le Ravageur cadre de test.

Ok, alors pourquoi avons-nous besoin de ce nouvel outil ?

La principale motivation derrière la création de ce package est d’encourager davantage de personnes à écrire des tests pour leur code, en particulier les développeurs de plugins.

De nombreux développeurs de la communauté WordPress suivent le mantra : je peux voir que cela fonctionne parce que je l’ai essayé dans mon navigateur. C’est OK, mais il y a des problèmes avec ça.

Tout d’abord, cela prend du temps. Chaque fois que vous faites un changement, vous devez vous assurer qu’il fonctionne, mais aussi que vous n’avez rien cassé.

Deuxièmement, les gens font des erreurs. Nous ne sommes pas infaillibles et le code peut être mal utilisé d’une manière que vous n’auriez jamais cru possible. Vous seriez étonné de voir à quel point les gens peuvent être créatifs lorsqu’ils écrivent du code.

Les tests automatisés sont rapides et peuvent vous aider à tester divers cas qui se produiront lorsque vous exécuterez votre code.

Vous testez le comportement prévu (chemin heureux), et de manière rapide, vous pouvez ajouter des exemples de la façon dont votre code peut être utilisé d’une manière que vous n’aviez pas l’intention d’utiliser (chemin malheureux).

Il protège également votre code des régressions. Une régression de code se produit lorsque vous cassez involontairement une partie de votre code en ajoutant un nouveau code.

Le problème avec les tests mis en place jusqu’à présent

Les tests dans WordPress ne sont pas une nouveauté. Et ce n’est pas comme si vous ne pouviez pas configurer de tests pour votre code auparavant. Il existe des bibliothèques incroyables qui vous aideront à tout configurer comme navigateur wp.

Mais le problème est que la procédure de configuration est souvent maladroite.

Vous devez configurer une base de données distincte pour les tests et vous devez exécuter certains scripts, puis modifier les fichiers pour que tout fonctionne.

Avouons-le, ce n’est pas une chose simple à faire, et les développeurs sont par nature des créatures paresseuses (c’est pourquoi nous écrivons du code pour faire les choses pour nous 😄).

L’objectif de la configuration du test d’intégration wp-pest est d’éliminer tout ce travail supplémentaire.

Comment le configurer

Pour le mettre en place, votre projet doit utiliser Compositeur. C’est un moyen standard de facto d’ajouter des packages à votre code.

Dans votre type de terminal

composer require dingo-d/wp-pest-integration-test-setup --dev

Après avoir téléchargé le package et ses dépendances, vous pouvez configurer les tests de thème en tapant

vendor/bin/wp-pest setup theme

Ou, dans le cas où vous souhaitez mettre en place des tests pour votre plugin, vous pouvez écrire

vendor/bin/wp-pest setup plugin --plugin-slug=your-plugin-slug

En option, vous pouvez fournir un --wp-version paramètre, pour spécifier la version de WordPress sur laquelle vous souhaitez tester votre code.

En arrière-plan, une instance WordPress sera téléchargée et une base de données en mémoire sera configurée, ainsi que deux exemples de tests que vous pouvez exécuter.

Ensuite, en exécutant soit

vendor/bin/pest --group=unit

ou alors

vendor/bin/pest --group=integration

effectuera les tests.

La beauté de Pest est que sa syntaxe est conviviale pour les développeurs. Il a une documentation incroyable et une excellente syntaxe. Prenons un exemple simple. Supposons que vous enregistrez un type de publication personnalisé appelé “Livres”:

<?php

/**
 * Plugin Name: Test plugin
 * Desctiption: Test plugin
 * Version: 1.0.0
 * License: MIT
 */

function test_plugin_register_books_cpt() {
    $args = array(
        'label'              => esc_html__( 'Books', 'test-plugin' ),
        'public'             => true,
        'publicly_queryable' => true,
        'show_ui'            => true,
        'show_in_menu'       => true,
        'query_var'          => true,
        'rewrite'            => array( 'slug' => 'book' ),
        'capability_type'    => 'post',
        'has_archive'        => true,
        'hierarchical'       => false,
        'menu_position'      => null,
        'supports'           => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' ),
    );
 
    register_post_type( 'book', $args );
}
 
add_action( 'init', 'test_plugin_register_books_cpt' );

Après avoir exécuté la commande setup qui ajoute un exemple, un test appelé BooksCptTest.php ressemblerait à ceci :

<?php

namespace Tests\Integration;

beforeEach(function () {
	parent::setUp();
});

afterEach(function () {
	parent::tearDown();
});

test('Books custom post type is registered', function () {
	// We can use assertions from PHP_Unit.
	$this->assertNotFalse(has_action('init', 'test_plugin_register_books_cpt'));

	$registeredPostTypes = \get_post_types();

	// Or we can use expectations API from Pest.
	expect($registeredPostTypes)
		->toBeArray()
		->toHaveKey('book');
});

Fonctionnement vendor/bin/pest --group=integration nous donne la sortie suivante :

Installing...
Running as single site... To run multisite, use -c tests/phpunit/multisite.xml
Not running ajax tests. To execute these, use --group ajax.
Not running ms-files tests. To execute these, use --group ms-files.
Not running external-http tests. To execute these, use --group external-http.

   PASS  Tests\\Integration\\BooksCptTest
  ✓ Books custom post type is registered

  Tests:  1 passed
  Time:   0.14s

Conclusion

Et juste comme ça, vous avez la possibilité d’exécuter des tests d’intégration WordPress dans votre thème ou plugin. Les tests sont incroyables car non seulement ils nous protègent des erreurs, mais ils nous obligent également à écrire du code propre et testable. Cela est particulièrement vrai pour les plugins qui ont une logique compliquée ou qui communiquent avec des API tierces.

L’écriture de tests pour une telle base de code vous obligera à réfléchir à l’apparence de votre architecture de code afin que vous puissiez facilement écrire des tests automatisés – sans parler du temps et de l’argent que vous économiserez en n’ayant pas à tout tester manuellement.

Si vous pensez que c’est quelque chose dont vous pourriez bénéficier, n’hésitez pas à l’utiliser, et démarrer le référentiel sur GitHub.

Espérons que cela encouragera davantage de développeurs WordPress à utiliser des outils qui amélioreront leurs compétences en codage.