Unit Testing Theory (continued): Part 2

In the last article, we started discussing the theory of unit testing in WordPress. Specifically, we review our work on unit testing themes and plugins, then move onto discussing code units, how this impacts our testing, and we review unit testing in the larger world of software development.

We will continue to discuss the theory of unit testing in WordPress, but from the perspective of how it can help identify problems, drive architecture, document projects, and more.

Find problems and save time

Recall the previous content of this series, the traditional method of unit testing is this:

• Write a test, run it (knowing it will fail)
• Write a function to make this method pass.
• Run the test. If the test fails, continue working on the function; otherwise, go to the next one.

Yes, the first step is a bit dogmatic. Why waste time running something you know will fail, right? But, you get the point. But when you start applying this particular technique to development, you'll find that you develop a certain rhythm when writing code, and that's part of the whole goal.

But that’s only half of it – unit tests can actually help you catch problems early in development.

To understand this, it's best to review the idea.

Suppose you are developing a feature for a WordPress-based project where you will allow users to create user accounts without actually logging into the WordPress dashboard. This assumes you've set up a page template to handle registration, necessary verification, and code for generating passwords and emails.

You load a page in your browser and try to create some users - some with the same email address, some with incorrect passwords, some with illegal characters, etc. You get the idea - there are multiple ways to verify that it passes and fails. This is so rough! This means that every time you change the user registration function, you have to perform the same n registrations to ensure that no problems arise.

Or you can write a set of tests to handle it and run them every time the code changes.

So, yes, writing unit tests can take a lot of time, but look at the time saved every time you modify a unit of code. This is well worth it and can help catch issues early (i.e. before releasing to production) that might have been missed because someone forgot to mock one permutation of the test.

Self-recording

When writing unit tests, you not only improve the quality of your code by ensuring that the code actually works, but you also essentially provide developer-facing documentation.

If you are unit testing a feature built into your product, you will provide documentation on how the feature works, when it should fail, and when it should pass.

With that comes some assumptions: Specifically, you are logically naming and grouping your functions and their associated tests, and you are testing each function correctly.

With PHPUnit, WordPress unit tests can easily execute easy-to-read assertions. You simply declare assertTrue, assertFalse, or any other assertion available on the functions that make up your project.

Following the example above, this means you can write a function that ensures the user registration function fails when trying to register with an empty email address:

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

Maybe a simple example, but the point remains: your code becomes self-documenting and only requires you to write clear unit tests.

Architecture

Perhaps one of the most underrated advantages of unit testing is that it can help drive the architecture of a project. Typically, theme or plugin development can begin in one of two ways:

1. List the functions, draw the user interface, and then write the code
2. Draw a diagram of how the files work together, then write the code

These aren't inherently bad things, but I think they're weak (I'll be the first to admit that I do more than I care to share!). But the "write the code" step comes with a lot of responsibility, doesn't it?

It's so familiar to anyone who's been coding for a long time that you eventually realize, "Oh... I didn't think of that."

If you're lucky, this usually means you can write a helper method or another conditional to handle the case you ignored, but in the worst case, it means you may have to redesign your entire class or The entire set of functions that solve this problem.

Unit testing, while not perfect, can help alleviate this situation.

Consider the fact that from the beginning, you have a list of all the features you want your theme or plugin to offer. You haven't written any code yet, but maybe you have some type of UI sketch and/or a set of class diagrams.

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

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

代码的语言

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

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

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

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

这不是更容易阅读吗：

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

而不是这个？

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

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

结论

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

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