问如何在遗留项目中实现测试框架？

EN

G‘’day，

编辑：--我刚刚快速浏览了"单元测试的艺术“的第一章，它也可以作为免费PDF在图书网站上使用。它将为您提供一个很好的概述，您正试图做什么与一个单元测试。

我假设您将使用xUnit类型框架。一些初步的高层想法是：

1. 编辑：确保每个人都同意什么是好的单元测试。我建议使用上面的概述章节作为一个很好的起点，如果需要的话，从这里开始。想象一下，当人们对什么是“好的”单元测试有不同的理解时，人们会热情地跑去创建大量的单元测试。对于你来说，将来有25%的单元测试是无用的、可重复的、可靠的等等，这对你来说是很糟糕的。
2. 一次添加测试以覆盖小块代码。也就是说，不要创建一个单一的单块任务来添加现有代码库的测试。
3. 修改任何现有进程，以确保为编写的任何新代码添加新测试。使之成为代码评审过程的一部分，即必须为新功能提供单元测试。
4. 扩展任何现有的bug修复过程，以确保创建新的测试以显示是否存在该错误并证明该错误是否存在。注意:不要忘记回滚您的候选补丁，再次引入bug，以验证只有单个修补程序才纠正了问题，并且它没有被多种因素所修复。
5. 编辑:当您开始构建测试的数量时，开始运行它们，就像夜间的回归测试一样，以检查新功能没有破坏什么。
6. 成功地运行所有现有测试和候选错误评审过程的条目标准。
7. 编辑：开始保存测试类型的目录，即测试代码片段，以便更容易地创建新的测试。无时无刻不在重新发明轮子。为测试在代码库的一部分中打开文件而编写的单元测试与编写用于在代码库的不同部分中打开不同文件的测试代码的单元测试类似。对这些产品进行编目，使其易于找到。
8. 编辑：--在这里，您只修改现有类的几个方法，创建一个测试套件来保存该类的完整测试集。然后，只将要修改的方法的单个测试添加到此测试套件中。这使用xUnit termonology，因为我现在假设您将使用像PHPUnit这样的xUnit框架。
9. 使用标准约定来命名您的测试套件和测试，例如testSuite_classA，它将包含像test__test_function这样的单独测试。例如，test_fopen_bad_name和test_fopen_bad_perms等，这有助于在代码库周围移动和查看其他人的测试时将噪音降到最低。这也有利于帮助人们从一开始就开始命名他们的测试，释放他们的思想去做一些更有趣的事情，比如测试本身。
10. 编辑：，在这个阶段我不会使用TDD。根据定义，TDD将需要在更改到位之前出现的所有测试，因此在添加新的testSuites以覆盖您正在处理的类时，您将在整个地方都有失败的测试。相反，添加新的testSuite，然后根据需要添加单个测试，这样您的测试结果中就不会出现大量的失败测试噪音。而且，就像一猜所指出的，在这个时候增加学习TDD的任务会使你慢下来。当你有空闲时间时，把学习TDD作为一项要完成的任务。没那么难。
11. 因此，您需要一个工具来跟踪那些存在testSuite但还没有编写测试来覆盖类中其他成员函数的现有类。通过这种方式，您可以跟踪测试覆盖率有漏洞的地方。我在这里讲的是一个高层，在这里，您可以生成一个类和特定成员函数的列表，而这些类和特定的成员函数目前还没有测试。测试和testSuites的标准命名约定将对您有很大的帮助。

我会增加更多的点，因为我认为他们。

HTH

你应该给自己买一本有效地使用遗产代码。这将为您提供关于如何将测试引入未编写用于测试的代码的良好指导。

TDD很棒，但是您确实需要首先测试现有代码，以确保您所做的更改不会在引入更改时更改现有的所需行为。

然而，现在引入TDD会使您在返回之前慢很多，因为改造测试，即使是在您正在更改的区域，也会在变得简单之前变得更加复杂。

为了补充其他优秀的答案，我同意在一次访问中从0%到100%的覆盖率是不现实的--但是每次修复bug时，您绝对应该添加单元测试。

您说有相当多的bug和不愉快的客户--我会非常肯定地将严格的TDD集成到错误修复过程中，这比全面实现它容易得多。毕竟，如果确实存在一个需要修复的bug，那么创建一个可以复制它的测试就可以达到不同的目标：

• 它很可能是一个最小的测试用例来证明确实存在一个问题
• 如果您确信(目前正在失败的)测试突出了报告的问题，那么您将确定您的更改是否修复了它
• 它将永远作为一个回归测试，将防止同样的问题再次出现在未来。

向现有项目引入测试是困难的，而且可能是一个漫长的过程，但是在修复bug的同时进行测试是这样做的理想时机(与在“正常”意义上逐步引入测试的同时)，如果不抓住这个机会并从bug报告中制造柠檬水，那将是一种耻辱。:-)