Quels domaines tester à l'unité lors de la création d'un plugin?
Je suis un développeur de plugins n'ayant absolument aucune expérience du secteur. J'ai créé un simple plugin pour ajouter plusieurs contributeurs à une publication via metabox.
J'ai parcouru des tonnes de sites Web et j'ai appris que wp-cli et PHPUnit étaient nécessaires pour effectuer des tests unitaires, mais je n'ai aucune idée de ce qu'il faut tester, des fonctions/crochets à inclure ou à exclure pour le test, des précautions à prendre et de l'alimentation. données utilisateur factices à tester.
Est-ce que quelqu'un ici peut me guider à travers le processus?
Types de tests
Tout d'abord, notez que le "test unitaire" dans WordPress va généralement au-delà du test unitaire et ressemble davantage à un test fonctionnel/d'intégration. C'est plus une différence technique, mais si vous comprenez la différence entre ces différentes choses, vous pouvez parfois être dérouté par la façon dont WordPress "teste" les choses.
Lorsque vous demandez quelles parties du plug-in vous devez tester, vous devriez idéalement tout tester. Mais quant aux parties pour lesquelles vous devez effectuer des tests unitaires (ou d'intégration) et pour lesquelles vous devez utiliser des tests d'acceptation, le problème est différent.
Actuellement, pour mes plugins, j'utilise deux couches de tests différentes: les tests "unit" avec PHPUnit, et les tests d'acceptation exécutés dans le navigateur via WP Browser . Les tests unitaires testent la logique interne, alors que les tests d'acceptation vérifient que, lorsqu'un utilisateur utilise l'interface utilisateur de votre plugin, celle-ci fonctionne réellement.
Tester
Les choses à unité à tester sont:
- code qui modifie les valeurs dans la base de données
- code qui effectue des calculs
- code qui contient une autre logique
En gros, toute fonction à laquelle vous transmettez une valeur et qui fait quelque chose de ce genre avec elle, et/ou vous renvoie une valeur.
Pour tester ce type de code, vous écrivez un test qui appelle la fonction en question en lui transmettant des valeurs particulières, puis vous affirmez que le résultat renvoyé correspond à vos attentes. Ou, pour les fonctions qui modifient la base de données, vous pouvez affirmer que la base de données contient les valeurs attendues après l'appel de la fonction.
Ne pas tester
Le code qui est difficile à tester à l'unité, et certains diront peut-être que ne devrait pas être testé à l'unité, serait un code qui est essentiellement dédié à la sortie de contenu dans le navigateur. C'est là que les tests d'acceptation entreraient.
De plus, puisque vous mentionnez actions/filtres, vous vous demandez peut-être si vous devez vérifier qu'une fonction est liée à l'action correcte ou si une fonction que vous avez connectée à un filtre est réellement appliquée lorsque WordPress appelle ce filtre. Cela peut être nécessaire ou non, en fonction de l'action ou du filtre en question. En général, je ne teste pas ce genre de chose, car il s’agit généralement de quelque chose de mieux adapté aux tests fonctionnels/d’acceptation (bien que les tests d’acceptation ne les testent qu’indirectement).
Résumé
Donc, fondamentalement, la logique de test unitaire et les méthodes de base de données, l'acceptation teste l'interface utilisateur réelle de votre plugin. Pour que cela fonctionne bien, vous devez bien sûr séparer votre code de modèle/sortie de votre autre logique, ce qui est généralement une bonne idée.
Dans votre cas, vous constaterez peut-être que les tests d'acceptation sont vraiment plus utiles pour votre plug-in et que les tests unitaires ne sont pas vraiment nécessaires, car la plupart des tests seraient déjà testés par les tests d'acceptation. Cependant, avoir les deux serait généralement l'idéal.
Je dirais que, dans le cas de WordPress, les tests unitaires ne sont pas la seule chose à considérer: les tests fonctionnels/d'intégration/d'acceptation (vous choisissez les types les plus pertinents dans votre situation) sont également importants, surtout parce que c'est un écosystème et qu'il est important de vérifier que votre code fonctionne avec le reste des composants (et, en prime, même avec certains des principaux plugins, tels que WooCommerce, Yoast SEO, etc.).
Pour tout ce qui précède (y compris les tests unitaires mais non obligatoires), j’ai personnellement constaté que Codeception est un outil simple à utiliser. Luca effectue d'importants travaux liés à WordPress dans ce domaine, notamment avec ses extensions de wp-browser pour Codeception. Il a aussi un excellent blog qui en explique beaucoup.