单元测试理论（续）：第 2 部分

在上一篇文章中，我们开始讨论 WordPress 中的单元测试理论。具体来说，我们回顾了我们在单元测试主题和插件方面的工作，然后开始讨论代码单元，这如何影响我们的测试，并且我们回顾了更大的软件开发世界中的单元测试。

我们将继续讨论 WordPress 中的单元测试理论，但会从它如何帮助识别问题、驱动架构、记录项目等角度进行讨论。

发现问题，节省时间

回想一下本系列前面的内容，进行单元测试的传统方法是这样的：

编写测试，运行它（知道它会失败）

编写函数以使该方法通过。

运行测试。如果测试失败，则继续处理该功能；否则，转到下一个。

是的，第一步有点教条。为什么要浪费时间去运行一些你知道会失败的东西，对吧？不过，你明白了。但是当您开始将这种特殊技术应用于开发时，您会发现编写代码时会形成一定的节奏，而这是整个目标的一部分。

但这只是其中的一半——单元测试实际上可以帮助您在开发早期发现问题。

为了理解这一点，最好回顾一下这个想法。

假设您正在为基于 WordPress 的项目开发一项功能，您将允许用户在不实际登录 WordPress 仪表板的情况下创建用户帐户。这假设您已经设置了一个页面模板来处理注册、必要的验证以及用于生成密码和电子邮件的代码。

您在浏览器中加载页面，尝试创建一些用户 - 一些具有相同的电子邮件地址，一些具有不正确的密码，一些具有非法字符等。您明白了 - 有多种方法验证通过和失败。这太粗糙了！这意味着每次更改用户注册功能时，您都必须执行相同的 n 次注册，以确保不会出现任何问题。

或者您可以编写一套测试来处理它，并在每次代码更改时运行它们。

所以，是的，编写单元测试可能会花费大量时间，但看看每次修改代码单元时节省的时间。这是非常值得的，这可以帮助尽早发现问题（即在发布到生产之前），这些问题可能会因为有人忘记模拟测试的一种排列而被错过。

自我记录

在编写单元测试时，您不仅可以通过确保代码实际工作来提高代码质量，而且本质上还可以提供面向开发人员的文档。

如果您正在对产品中构建的功能进行单元测试，您将提供有关功能如何工作、何时应该失败以及何时应该通过的文档。

随之而来的是一些假设：具体来说，您正在逻辑地命名和分组您的函数及其相关测试，并且您正在正确测试每个函数。

通过 PHPUnit，WordPress 单元测试可以轻松执行易于阅读的断言。您只需声明assertTrue、assertFalse 或组成项目的函数上可用的任何其他断言。

按照上面的示例，这意味着您可以编写一个函数来确保用户注册函数在尝试使用空电子邮件地址注册时失败：

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

也许是一个简单的例子，但要点仍然是：您的代码变得自文档化，并且只需要您编写清晰的单元测试。

架构

也许单元测试最被低估的优势之一是它可以帮助驱动项目的架构。通常，主题或插件开发可以通过以下两种方式之一开始：

列出函数，绘制用户界面，然后编写代码

画出文件如何协同工作的图表，然后编写代码

这些本质上并不是坏事，但我认为它们很弱（我将是第一个承认我所做的事情比我想分享的要多的人！）。但是“编写代码”步骤需要承担很多责任，不是吗？

对于任何一个长时间编写代码的人来说，你都太熟悉了，以至于你最终会意识到，“哦......我没有想到这一点。”

如果你幸运的话，这通常意味着你可以编写一个辅助方法或另一个条件来处理你忽略的情况，但在最坏的情况下，这意味着你可能必须重新设计你的整个类或整个集合解决这个问题的函数。

单元测试虽然并不完美，但可以帮助缓解这种情况。

考虑一下这样一个事实：从一开始，您就列出了您希望主题或插件提供的所有功能。您尚未编写任何代码，但也许您有某种类型的 UI 草图和/或一组类图。

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

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

代码的语言

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

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

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

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

这不是更容易阅读吗：

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

而不是这个？

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

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

结论

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

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

以上就是单元测试理论（续）：第 2 部分的详细内容，更多请关注本网内其它相关文章！