单元测试程序代码有效吗？

在当前的项目中，希望将单元测试纳入我们的开发周期，以避免似乎不断渗入我们的代码中的错误数量。问题在于，意大利面条代码的程序化程度为95％，我从来没有使用过单元测试（我所有的单元测试经验都使用过OOP代码）

因此，我的问题简而言之是用我们当前的代码库进行单元测试，还是建议将其推迟到将应用程序迁移到适当的OOP框架后才是明智的选择？

PS：当我尝试将这个问题的样式与语言无关时，我认为说明所涉及的应用程序使用PHP和javascript将有助于提供更具体的答案，从而可以回答该问题，因为从经验来看，此类应用程序大多会发生这种情况。

单元测试与对象配合得很好，特别是因为它提供了许多精美的功能，例如模拟对象，有助于更快地创建更好的测试。

话虽这么说，没有什么禁止在程序代码库上进行单元测试的。在OOP中，大多数单元测试都是通过向其传递一些参数并期望结果或特定类型的异常的测试方法。程序代码也可以做到这一点。只是要测试功能，而不是测试方法。

请注意，您必须：

• 隔离必须测试的功能和不需要的功能。在OOP中，这很简单：不必测试私有方法，因为调用者永远无法直接访问它们。在您的过程代码中，某些功能可能像这样，不需要测试。

• 考虑一下全球范围。这个问题也存在于OOP中，但是如果您说必须测试意大利面条式代码，那么编写此代码的人很可能会养成不良习惯，例如过多使用全局范围，并在内部做一些疯狂的事情，例如更改$_GET或$_POST数组功能。

• 处理函数外部的代码。这是一个更复杂的情况，但仍然可能。您可以require_once在页面上查看会发生什么并通过ob_start/ 捕获输出ob_get_clean，也可以在测试套件中执行HTTP请求并通过解析HTML分析响应。这实际上不是UI测试：在这里，您不必关心页面上的按钮是显示在左侧还是右侧，或者链接是用大红色大写字母还是用小蓝色大写字母。您关心的是通过DOM查找一些HTML元素，并将它们的内容与预期的内容进行比较。

• 测试响应代码。require_once输出缓冲的效果很好，但是您还必须测试Web应用程序如何处理错误。例如，如果测试的预期结果是“ 404未找到”，则必须执行HTTP请求才能知道响应是什么。

建议将其推迟到将应用程序迁移到适当的OOP框架

在迁移到另一个平台之前（而非之后）进行一些自动测试。在进行迁移时（而不是之后）添加更多测试。如果这些测试是“集成测试”或单元测试，则必须自行决定，但是通常您可以对两种类型都使用自己喜欢的xUnit测试框架。

开始单元测试的最有效方法是确定最常发生或成本最高的错误类别。然后创建针对这些错误的测试。

这些测试的实施方式在范例和语言之间会有所不同。影响您进行单元测试的能力的最大因素是代码的质量。少使用范式。请记住，单元测试是关于单独测试代码的“单元”。任何影响您隔离代码“单元”能力的因素都会使测试更加困难。

• 使用全局变量
• 副作用
• 紧密耦合的代码
• 不良耦合代码
• 大量的条件
• 设计不当的“单位”

与语言范例相比，所有这些将对测试的难度产生更大的影响。

任何时候只要您可以自动测试部分代码，单元测试就可以有效。因此，问题不是程序代码是否可以有效地进行单元测试，问题是此代码可以进行单元测试。那将取决于它读取多少状态以及设置多少状态。理想情况下，两者的答案都是零，但如果不是，您仍然可以对其进行测试。

与往常一样，您需要权衡代码正确性的可信度和获得该可信度的成本。请记住，单元测试的部分收益是明确识别依赖关系，从这种意义上讲，与OOP代码相比，对单元测试过程代码进行单元测试更为有效。

我认为不可能对过程代码进行真正的单元测试。主要问题是每个过程可能会具有许多无法解决的依赖项。最好的测试是集成测试。许多个月前，我在MS Access中使用VB6模块和VBA模块做过类似的事情。

就是说，如果您可以在导致最大痛苦的方法周围放置测试支架，那一定很有价值，对吗？