回归测试WordPress网站的最佳做法？

大家好，

我想听听其他人以WordPress为平台向客户提供复杂的非博客解决方案的情况，他们正在使用什么进行自动回归测试？

对于那些不熟悉术语“回归测试”的人， Wikipedia将其定义为：

回归测试是任何类型的软件测试，其旨在通过重新测试程序来在对程序进行更改（例如，错误修正或新功能）后发现软件错误。回归测试的目的是确保更改（例如错误修正）不会引入新的错误。

更有说服力的Wikipedia指出以下内容正是我目前在一个项目上所经历的：

经验表明，随着软件的修复，新故障的出现和/或旧故障的再次出现是很普遍的。有时会出现重新出现的情况，因为修订是由于不良的修订控制实践（或修订控制中简单的人为错误）而丢失的。通常，解决问题的方法是“脆弱的”，因为它可以在首次发现问题的狭窄情况下解决问题，而在软件的整个生命周期内可能会出现的更一般情况下，则无法解决问题。通常，对一个区域中的问题的修复无意间导致了另一区域中的软件错误。最后，通常情况是，当重新设计某些功能时，在重新设计中会犯一些与该功能的原始实现相同的错误。

有了动作和过滤器的全局性，我发现随着我添加更多客户端请求的功能，复杂性开始增加，并且很难获得稳定的复杂插件，尤其是当它使用大量的调用WP_Query和更新数据库的情况时。

我认为解决方案是使用一系列“测试用例”设置回归测试以构成“测试套件”。从概念上讲，测试HTTP GET请求的HTML输出并不难。但是，当您必须通过管理控制台登录和/或测试jQuery交互时必须进行测试时，情况变得有些复杂。

我将其设置为社区Wiki，希望我们可以在此处收集最佳实践，但如果有其他WordPress专业人员正在使用，我真的很想听听流程。

如果WP测试套件没有那么坏，并且设计和编写WP时可以实际对其进行测试，那么PHPUnit就会浮现在脑海。;-)

更严重的是，您可以使用单元测试之类的工具从功能的角度测试所有想要的插件。问题是这些测试不能保证它们会抓住WP升级带来的微妙机会，更不用说一旦插入定制的WP安装中，它们就可以继续工作。

在我所见过的丰富多彩的事情中，有：

• WP API中的细微变化会影响插件的功能，例如，您用来获取术语ID的钩子，现在它正在获取术语分类ID。（有可能您的测试词可以方便地使用相同的ID）。

• WP API中的细微变化会导致您接收到一个WP_Error对象，而不是先前预期的false错误输入值。

• 您的插件是从mu-plugins文件夹中添加的，从而导致代码流稍有不同。

• 您的插件运行良好，直到启用了memcached或其他持久存储。

• 您的插件运行良好，直到被鄙视的switch_to_blog（）被调用为止。

• 插件在被调用时会更改它所驻留的钩子，并且会在不知不觉间中断它的副作用。

• 一个插件（un？）会弄乱您的输入或输出数据，以至于即使您没有错，事情看起来也很糟糕。

我可以不停地扩展列表，但是那些将是破坏我自己的插件的关键项。可以说，这两项在单元测试中都是可以捕获的。如果您足够耐心的话，接下来的两个也是，但是我认为WP不应在事情发生时改变工作方式。switch_to_blog（）的错误实现不会进行大量测试。最后两个是无法检验的。

哦，而且...甚至还不让我着手处理附件，自动草稿，修订，菜单项的猛烈攻击，以及最终存储在posts表中的内容。

祝好运... ：-）

您应该强烈考虑硒。

它允许您记录操作（例如，将数据输入表单，单击链接），然后可以执行断言。它还与PHPUnit集成。我强烈建议您查看两分钟的演示。

硒可能有用，但我认为在现代，您会发现Codeception更好，更易于使用。对于最简单的视觉回归测试，它甚至具有扩展功能，可以获取屏幕截图并自动为您比较。

当然，Codeception WebDriver测试可以走得更远并执行功能回归测试。您可以填写并提交表格，单击网站上的按钮和链接，执行任何JS等。您可以在测试中使用Firefox或Chrome这样的真实浏览器，也可以使用PhantomJS进行无头测试。这意味着，如果您愿意，甚至可以在Travis CI上为其插件运行WebDriver测试，作为其构建过程的一部分。

甚至还有几个特定于WordPress的库可帮助您入门：

• WP浏览器
• WP Codeception