Plus je travaille dans WordPress, plus j’essaie de faire des tests unitaires autant une partie de mon développement que de développer l’ensemble de fonctionnalités réel. (C’est ce que tous les professionnels disent que nous devons faire, de toute façon.)
Mais sérieusement, cela améliore la qualité car, si pour aucune autre raison, quelque chose se casse, vous pouvez voir quel test échoue ou même si vous avez manqué la couverture dans certaines zones.
Je ne suis pas de l’état d’esprit de certains selon lesquels vous devez avoir une couverture de code à 100% (et il y a des raisons pour lesquelles je pense cela), mais je pense qu’il est important d’avoir autant de couverture de code que possible de code qui n’est pas directement à WordPress.
Tester le code dans WordPress
Je ne sais pas si cela semble déroutant ou non, mais l’un des pièges dans lesquels je suis tombé au début lorsque je travaillais avec les tests unitaires et WordPress était d’écrire des tests par rapport au code principal de WordPress.
Je le fais encore parfois (et vous pouvez demander à ceux avec qui je travaille si c’est vrai), même si je m’améliore.
En ce qui me concerne, WordPress lui-même peut être traité comme une boîte noire. C’est une fondation sur laquelle vit votre application. Il existe déjà des tests autour du noyau WordPress. Devrait-il y en avoir plus? Bien sûr. Est-ce que ce qu’ils ont est suffisant? D’après mon expérience, oui, mais nous utilisons tous un sous-ensemble différent de ces fonctionnalités.
Le point que je comprends est le suivant: chaque fois que vous travaillez sur un projet construit sur WordPress ; vous n’avez pas besoin d’écrire des tests sur du code comme add_menu_pageou wp_enqueue_script.
Nous savons que ces fonctions fonctionnent.
Concentrez-vous plutôt sur le code spécifique à votre domaine. Autrement dit, concentrez-vous sur le code que vous et votre équipe écrivez. Ce sera le domaine de spécialité qui sera unique dans le projet, et ce sera le domaine qui sera finalement responsable de la résolution d’un problème donné.
Si vous visez une couverture à 100 % juste pour une couverture à 100 %, alors vous n’écrivez pas de tests unitaires pour la bonne raison. Au lieu de cela, visez le degré le plus élevé de couverture de code qui teste suffisamment votre code. C’est ce qui renforcera la qualité.