Share
Dans le dernier article, nous avons abordé la théorie des tests unitaires dans WordPress. Plus précisément, nous avons examiné notre travail sur les thèmes de tests unitaires et les plugins, puis nous avons commencé à discuter des unités de code et de leur impact sur nos tests. Nous avons également examiné les tests unitaires dans le monde plus vaste du développement logiciel..
Nous allons continuer à discuter de la théorie des tests unitaires dans WordPress, mais nous allons le faire en considérant comment cela peut aider à identifier les problèmes, à piloter l'architecture, à documenter le projet, etc..
Rappelez-vous, plus tôt dans cette série, que la manière traditionnelle de faire des tests unitaires est la suivante:
Oui, la première étape est un peu dogmatique. Pourquoi perdre des minutes à faire fonctionner quelque chose qui va échouer, n'est-ce pas? Pourtant, vous avez l’idée. Mais au fur et à mesure que vous commencerez à appliquer cette technique particulière au développement, vous découvrirez que vous développerez un certain rythme pour écrire votre code, ce qui fait partie de l'objectif global..
Mais ce n’est que la moitié: les tests unitaires peuvent réellement vous aider à détecter les problèmes plus tôt dans le développement..
Pour comprendre, il est probablement préférable de revenir dans l'idée.
Supposons que vous travaillez sur une fonctionnalité pour un projet basé sur WordPress dans laquelle vous allez permettre aux utilisateurs de créer un compte utilisateur sans se connecter au tableau de bord WordPress. Cela suppose que vous ayez une configuration de modèle de page pour gérer l'enregistrement, la validation nécessaire en place et le code permettant de générer des mots de passe et des courriels..
Vous chargez la page dans votre navigateur, essayez de créer quelques utilisateurs - certains avec la même adresse e-mail, d'autres avec des mots de passe incorrects, d'autres avec des caractères non autorisés, etc. passer et échouer. C'est rugueux! Cela signifie que chaque fois que la fonction d'enregistrement de l'utilisateur est modifiée, vous devez effectuer le même nombre d'inscriptions pour vous assurer que rien n'est cassé..
Ou vous pouvez écrire une suite de tests pour en prendre soin et les exécuter à chaque changement de code.
Alors, oui, écrire des tests unitaires peut prendre beaucoup de temps au début, mais regardez le temps gagné chaque fois que vous modifiez une unité de code. Cela en vaut la peine et cela peut aider à identifier les problèmes dès le début, c'est-à-dire avant sa sortie en production, ce qui aurait pu être oublié car quelqu'un a oublié de simuler une permutation du test..
En ce qui concerne la rédaction de tests unitaires, vous améliorez non seulement la qualité de votre code en veillant à son efficacité, mais vous fournissez également une documentation orientée développeur..
Si vous testez les fonctionnalités que vous intégrez à votre produit, vous allez fournir une documentation indiquant comment les fonctions sont censées fonctionner, quand elles devraient échouer et quand elles devraient réussir..
Voici quelques hypothèses: En particulier, vous nommez et regroupez logiquement vos fonctions et leurs tests associés et vous testez correctement chaque fonction..
Grâce à PHPUnit, les tests unitaires WordPress facilitent la réalisation d’assertions faciles à lire. Vous déclarez simplement assertTrue, assertFalse ou toute autre assertion disponible sur les fonctions qui composent votre projet..
Suivant notre exemple ci-dessus, cela signifie que vous pourriez écrire une fonction pour vous assurer que la fonction d’enregistrement d’utilisateur échoue lorsqu’elle tente d’être enregistrée avec une adresse e-mail vide:
Accentsconagua
$ this-> assertFalse (registerNewUser (")); Un exemple simple, peut-être, mais le point demeure: votre code devient auto-documenté et il vous suffit de rédiger des tests unitaires clairs..
L'un des avantages les plus minimisés des tests unitaires est peut-être qu'il peut vous aider à piloter l'architecture de votre projet. En règle générale, le développement de thèmes ou de plugins peut démarrer de deux manières:
Ce ne sont pas intrinsèquement mauvais, mais je pense qu’ils sont faibles (et je serai le premier à admettre que j’ai fait les deux plus que ce que j’aimerais partager!). Mais l’étape "écriture du code" suppose beaucoup, n'est-ce pas?
Pour tous ceux qui écrivent du code depuis assez longtemps, vous savez très bien que vous finissez par atteindre le point où vous réalisez, "Oh… je n'y ai pas pensé."
Si vous êtes chanceux, cela signifie généralement que vous pouvez écrire une méthode d'assistance ou une autre condition pour gérer le cas que vous avez négligé, mais dans le pire des cas, vous devrez peut-être retravailler toute votre classe ou tout votre ensemble de fonctions. répondre à ce problème.
Les tests unitaires, même s'ils ne sont pas parfaits, peuvent contribuer à atténuer ce problème..
Considérez le fait que, dès le début, vous énumérez toutes les fonctionnalités que vous souhaitez que votre thème ou votre plugin offre. Vous n'avez encore écrit aucun code, mais vous avez peut-être une sorte d'esquisse de l'interface utilisateur et / ou un ensemble de diagrammes de classes.
Ensuite, vous commencez à écrire les tests que vous allez écrire afin de tester votre projet. Rappelez-vous qu'une partie des tests unitaires consiste à décomposer le code en unités les plus atomiques possibles. Vous devez donc écrire des tests unitaires pour chacun de ces éléments., ahem, des unités.
En raison de la nature des tests unitaires, vous pensez de manière différente à votre code: plutôt que "écrire du code", vous pensez "écrire des tests", et parce que vous devez penser à un niveau plus atomique, vous pouvez aidez-vous mais considérez les cas marginaux qui sont si souvent regroupés dans "écrire du code".
En tant que développeurs, nous sommes beaucoup trop à l'aise avec l'utilisation de conventions qui renforcent continuellement le fait que nous écrivons du code. Je veux dire par là que nous avons tendance à fournir des noms de variables abrégés, des noms de fonctions cryptiques et des noms de classes qui ne signifient peut-être rien en dehors de vous-même ou de l'équipe qui travaille sur votre projet..
Le test unitaire n'est pas nécessairement la clé pour écrire un code plus facile à lire, mais il peut aller un peu plus loin en fournissant des noms de fonctions plus propres..
Rappelez-vous du premier livre de programmation que vous avez lu, du premier cours d'informatique que vous avez suivi ou du premier élément de code source ouvert que vous avez vu, les noms de méthodes sont généralement des verbes. Pourquoi ne devraient-ils pas l'être? Les méthodes sont des moyens d'encapsuler du code qui fait des choses. Mais comme nous travaillons sur des projets de plus en plus longs, nous devenons de plus en plus paresseux et notre code va de "register_user_and_email_password ()" à "nouveau compte()".
Évidemment, le premier est plus propre que le dernier, mais si nous recherchons des tests unitaires de qualité et que nous voulons nous assurer que nos tests unitaires sont faciles à lire, leur nom de fonction doit être: facile à lire.
N'est-ce pas plus facile à lire:
$ this-> assertFalse (register_user_and_email_password (")); Au lieu de cela?
$ this-> assertFalse (new_account (")); Encore une fois, c’est peut-être un exemple simple, mais le principe reste le même: écrire de bons tests unitaires afin d’aider à auto-documenter le code qui régit le langage de vos fonctions.
Nous avons parlé des bases du test unitaire ainsi que des principaux avantages, mais nous n’avons pas encore discuté des inconvénients du test unitaire et nous n’avons même pas cherché à l’incorporer à notre flux de travail..
Donc, dans le prochain article, nous allons essayer de faire exactement cela.
