Théorie des tests unitaires (suite) : partie 2

Dans le dernier article, nous avons commencé à discuter de la théorie des tests unitaires dans WordPress. Plus précisément, nous passons en revue notre travail sur les thèmes et les plugins de tests unitaires, puis passons à la discussion des unités de code, de leur impact sur nos tests, et nous passons en revue les tests unitaires dans le monde plus large du développement logiciel.

Nous continuerons à discuter de la théorie des tests unitaires dans WordPress, mais du point de vue de la manière dont ils peuvent aider à identifier les problèmes, à piloter l'architecture, à documenter les projets, etc.

---

Trouvez des problèmes et gagnez du temps

Rappelons-nous plus tôt dans cette série que l'approche traditionnelle des tests unitaires est la suivante :

• Écrivez un test, exécutez-le (en sachant qu'il échouera)
• Écrivez une fonction pour faire passer cette méthode.
• Faites le test. Si le test échoue, continuez à travailler sur la fonction ; sinon, passez à la suivante.

Oui, la première étape est un peu dogmatique. Pourquoi perdre du temps à exécuter quelque chose dont vous savez qu'il échouera, n'est-ce pas ? Mais vous comprenez. Mais lorsque vous commencez à appliquer cette technique particulière au développement, vous constaterez que vous développez un certain rythme lors de l'écriture du code, et cela fait partie de l'objectif général.

Mais ce n’est que la moitié : les tests unitaires peuvent en réalité vous aider à détecter les problèmes dès le début du développement.

Pour comprendre cela, il est préférable de revoir cette idée.

Supposons que vous développiez une fonctionnalité pour un projet basé sur WordPress dans laquelle vous permettrez aux utilisateurs de créer des comptes d'utilisateurs sans réellement se connecter au tableau de bord WordPress. Cela suppose que vous avez configuré un modèle de page pour gérer l'inscription, la vérification nécessaire et le code pour générer des mots de passe et des e-mails.

Vous chargez une page dans votre navigateur, essayez de créer des utilisateurs - certains avec la même adresse e-mail, certains avec des mots de passe incorrects, certains avec des caractères illégaux, etc. Vous voyez l’idée : il existe plusieurs façons de vérifier qu’il réussit et échoue. C'est tellement dur ! Cela signifie que chaque fois que vous modifiez la fonction d'enregistrement des utilisateurs, vous devez effectuer les mêmes n enregistrements pour vous assurer qu'aucun problème ne survient.

Ou vous pouvez écrire un ensemble de tests pour le gérer et les exécuter à chaque fois que le code change.

Alors oui, écrire des tests unitaires peut prendre beaucoup de temps, mais regardez le temps gagné à chaque fois que vous modifiez une unité de code. Cela en vaut la peine et peut aider à détecter rapidement les problèmes (c'est-à-dire avant la mise en production) qui auraient pu être manqués parce que quelqu'un a oublié de se moquer d'une permutation du test.

---

Auto-enregistrement

Lors de l'écriture de tests unitaires, vous améliorez non seulement la qualité de votre code en vous assurant qu'il fonctionne réellement, mais vous fournissez également essentiellement une documentation destinée aux développeurs.

Si vous testez unitairement une fonctionnalité intégrée à votre produit, vous fournirez une documentation sur le fonctionnement de la fonctionnalité, quand elle doit échouer et quand elle doit réussir.

Cela implique quelques hypothèses : plus précisément, vous nommez et regroupez logiquement vos fonctions et leurs tests associés, et vous testez chaque fonction correctement.

Avec PHPUnit, les tests unitaires WordPress peuvent facilement exécuter des assertions faciles à lire. Vous déclarez simplement assertTrue, assertFalse, ou toute autre assertion disponible sur les fonctions qui composent votre projet.

En suivant l'exemple ci-dessus, cela signifie que vous pouvez écrire une fonction qui garantit l'échec de la fonction d'enregistrement de l'utilisateur lorsque vous essayez de vous inscrire avec une adresse e-mail vide :

$this->assertFalse( registerNewUser( '' ) );

Un exemple simple peut-être, mais le point demeure : votre code devient auto-documenté et ne nécessite que vous écriviez des tests unitaires clairs.

---

Architecture

L'un des avantages les plus sous-estimés des tests unitaires est peut-être qu'ils peuvent aider à piloter l'architecture de votre projet. En règle générale, le développement d'un thème ou d'un plugin peut démarrer de deux manières :

1. Listez les fonctions, dessinez l'interface utilisateur, puis écrivez le code
2. Dessinez un diagramme de la façon dont les fichiers fonctionnent ensemble, puis écrivez le code

Ce ne sont pas des choses intrinsèquement mauvaises, mais je pense qu’elles sont faibles (je serai le premier à admettre que je fais plus que ce que je veux partager !). Mais l’étape « écrire le code » comporte beaucoup de responsabilités, n’est-ce pas ?

C'est si familier à quiconque code depuis longtemps qu'on finit par se rendre compte : "Oh... je n'y avais pas pensé."

Si vous avez de la chance, 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 ignoré, mais dans le pire des cas, cela signifie que vous devrez peut-être repenser toute votre classe ou toute votre fonction de collection pour résoudre ce problème. .

Les tests unitaires, bien qu'ils ne soient pas parfaits, peuvent aider à atténuer cette situation.

Pensez au fait que dès le début, vous disposez d’une liste de toutes les fonctionnalités que vous souhaitez que votre thème ou plugin offre. Vous n'avez pas encore écrit de code, mais vous disposez peut-être d'un type de croquis d'interface utilisateur et/ou d'un ensemble de diagrammes de classes.

接下来，您开始编写要编写的测试以测试您的项目。回想一下，单元测试的一部分是将代码分解为尽可能的原子单元，因此您的任务是为每个单元编写单元测试，咳咳。

由于单元测试的性质，您本质上会以不同的方式思考您的代码：您正在考虑“编写测试”，而不是“编写代码”，并且因为您必须在更原子的级别上进行思考，您会情不自禁地考虑经常被归入“编写代码”的边缘案例。

---

代码的语言

作为开发人员，我们非常习惯使用不断强化我们编写代码的约定。我的意思是，我们倾向于提供缩写的变量名称、神秘的函数名称和类名称，这些名称对于您自己或项目团队之外的任何人来说可能没有任何意义。

单元测试不一定是编写更易于阅读的代码的关键，但它可以进一步帮助提供更清晰的函数名称。

回想一下您读过的第一本编程书、您参加的第一堂计算机科学课或者您看到的第一段开源代码，方法名称通常是动词。为什么他们不应该这样？方法是封装代码的方法，做一些事情。但随着我们在项目上工作的时间越来越长，我们变得越来越懒，我们的代码从“register_user_and_email_password()”变成“new_account()”。

显然，前者比后者更清晰，但如果我们致力于高质量的单元测试，并且希望确保我们的单元测试易于阅读，为了使它们易于阅读，我们的函数名称必须易于阅读。

这不是更容易阅读吗：

$this->assertFalse( register_user_and_email_password( '' ) );

而不是这个？

$this->assertFalse( new_account( '' ) );

同样，这也许是一个简单的示例，但原则仍然是：编写良好的单元测试，以帮助自我记录驱动函数语言的代码。

---

结论

我们已经讨论了单元测试的基础知识以及主要优点，但是我们还没有讨论单元测试带来的缺点，我们甚至还没有考虑如何将其合并到我们的项目中。工作流程。

因此，在下一篇文章中，我们将尝试做到这一点。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!