如果WP测试套件没有那么坏，如果WP的设计和编写方式确实能够正确地进行测试，PHPUnit就会出现在脑海中

更严重的是，您可以通过单元测试等从功能角度测试插件。问题是，这些测试不能保证它们能抓住WP升级带来的细微机会，更不用说一旦插入定制的WP安装，它们还能继续工作。

在我看到的五彩缤纷的事情中：

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

WP API中的细微变化会导致您收到WP_Error 对象，而不是以前期望的值false 作为错误输入。

您的插件是从mu plugins文件夹中添加的，因此产生了细微不同的代码流。

在启用memcached或其他持久存储之前，您的插件工作正常。

您的插件运行良好，直到被鄙视的switch\\u to\\u blog（）被调用。

当插件被调用时，它会改变它所在的钩子，并作为副作用在不知不觉中中断它。

插件（un？）故意将输入或输出数据弄乱，使事情看起来很糟，即使你没有错。

我可以不断扩展列表，但这些都是破坏我自己插件的关键因素。这两个项目可以通过单元测试来捕获。如果你有足够的耐心，接下来的两个也是一样，但我认为WP不应该改变事情发生时的工作方式。对于switch\\u to\\u blog（）的错误实现，再多的测试也无济于事。最后两个是无可救药的不稳定。

哦，还有。。。甚至不要让我开始了解附件、自动草稿、修订、菜单项以及最终存储在posts表中的其他内容。

祝你好运…：-）