我目前正在处理一个现有的 PHP 项目。当前的代码设计不是很好，并且错误开始堆积。所以我想要的是添加一个全面的测试套件，使其更加可靠。
已经有一些单元测试是用 PHP 单元编写的，但是，测试覆盖率并不是那么好。该项目并没有真正遵循 TDD 或任何类型的测试密集型流程。我希望尽可能地测试所有内容。但问题是我不确定是否可以为现有代码添加测试。正如我所提到的，代码结构不是很好，因此添加测试可能会变得非常麻烦和困难。
有没有更好的方法在这样的项目中添加单元测试？还是我应该重写项目？也许一个模块一个模块？
【问题讨论】：
标签： php unit-testing phpunit
尝试将单元测试添加到现有应用程序时出现的大多数问题通常是因为该应用程序没有将其功能划分为可以有效测试的类和方法。
这实际上不仅是 TDD 的主要优势之一，而且是在开发应用程序时编写测试的良好实践。这些测试迫使您编写具有明确目的和尽可能少副作用的简洁方法。
完全重写将是最终的解决方案，但我怀疑您是否有时间和精力这样做；而且，这样的行为可能不是我完全需要的！
老实说，根据我的经验，最好的方法是立即开始为每个模块编写测试，并在需要的地方进行重构。从核心元素开始，例如用户注册和管理位，然后再进一步。
这似乎是一项艰巨的任务，它可能会让您觉得您的工作是徒劳的，但从长远来看，这些测试将大大减少调试应用程序所花费的时间！
进一步阅读：
【讨论】：
我们只是开始测试我们可以测试的内容。处理数据和返回结果的类现在可以编写测试，这些测试可以工作，并验证可以测试类的一小部分。开始时令人生畏，但我们现在有大约 45% 的代码覆盖率，有 3000 多个测试。当人们重构代码时，这些测试当前会捕获错误。
我们试图隔离使测试更容易的模块和类，并且一些测试只是测试构造函数、公共接口等......如果它们发生变化，那么就会出现问题，因为某些东西可能会中断。
当发现新的错误时，我们首先尝试编写一个测试来说明错误，然后我们更改代码以解决测试。这使我们的测试继续前进。
每天，我们都会添加一些测试，直到结果开始令人鼓舞，测试基础更大，代码覆盖范围更广。在此过程中的某个时刻，我们的测试实际上发现了当人们添加或更改破坏某些遗留接口的代码时所产生的问题。这是自动化测试的第一个成功案例，因为它是在没有手动测试旧输入文件的情况下发现的，可能没有经过测试。
【讨论】：
在尝试将测试添加到已经存在的代码库时要非常小心。正如 Andrei 指出的那样，任务非常庞大，如果从一开始就集成测试，TDD 效果最好。
尝试将测试添加到您的核心功能中，并通过开发人员测试其余部分以老式方式修复错误。
【讨论】：