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

Question

我有一个用PHP和Javascript编写的大项目.问题在于它变得如此庞大且不可维护,以至于改变代码的一小部分会令人不安并且可能会破坏很多其他部分.

我真的很难测试我自己的代码(事实上,其他人每天指出这一点),这使得维护项目变得更加困难.

项目本身并不复杂或复杂,它的构建方式更加复杂:我们在进行测试时没有预定义的规则或列表.这通常会导致许多错误和不满意的客户.

我们开始在办公室讨论这个问题,并提出了开始使用测试驱动开发而不是像地狱一样开发的想法,也许稍后会进行测试(这几乎总是最终会被修复错误).

在那个背景之后,我需要帮助的事情如下:

1. 如何将测试框架实现到现有项目中？(制作和计算3年)

2. 有哪些框架可供测试？我想我需要一个Javascript框架和一个PHP框架.

3. 什么是测试图形用户界面的最佳方法？

我之前从未使用过单元测试,所以这对我来说真的是一个未知领域.

Answer 1

天儿真好,

编辑:我刚刚浏览了" 单元测试艺术 "的第一章,该书也可以在本书的网站上以免费PDF格式获得.它将为您提供一个很好的概述,您正在尝试使用单元测试.

我假设您将使用xUnit类型框架.一些最初的高层次想法是:

1. 编辑:确保每个人都同意什么是良好的单元测试.我建议使用上面的概述章作为一个很好的起点,如果需要,可以从那里开始.想象一下,让人们热情地跑去创造大量的单元测试,同时对"好"的单元测试有不同的理解.将来25%的单元测试无用,可重复,可靠等等,这对你来说太可怕了.
2. 添加测试以一次覆盖小块代码.也就是说,不要创建单个整体任务来为现有代码库添加测试.
3. 修改任何现有进程以确保为编写的任何新代码添加新测试.使其成为代码审查过程的一部分,必须为新功能提供单元测试.
4. 扩展任何现有的错误修复过程,以确保创建新的测试以显示存在并证明没有错误.注意:不要忘记回滚您的候选修复程序再次引入该错误,以验证它只是纠正问题的单个修补程序,并且不是由多种因素组合修复的.
5. 编辑:当您开始构建测试数量时,开始将它们作为夜间回归测试运行,以检查新功能是否已破坏任何内容.
6. 为候选bugfix的审查过程成功运行所有现有测试和进入标准.
7. 编辑:开始保留测试类型的目录,即测试代码片段,以便更轻松地创建新测试.没有任何意义重新发明轮子.为测试在代码库的一部分中打开文件而编写的单元测试将类似于写入测试代码的单元测试,该测试代码在代码库的不同部分打开不同的文件.将这些目录编目以便于查找.
8. 编辑:您只修改现有类的几个方法,创建一个测试套件来保存该类的完整测试集.然后,仅将要修改的方法的各个测试添加到此测试套件中.这使用xUnit termonology,因为我现在假设您将使用像PHPUnit这样的xUnit框架.
9. 使用标准约定来命名测试套件和测试,例如testSuite_classA,然后包含各个测试,如test__test_function.例如,test_fopen_bad_name和test_fopen_bad_perms等.这有助于最小化在代码库中移动并查看其他人的测试时的噪音.它还有助于帮助人们在首先命名他们的测试时,通过释放他们的思想来处理更有趣的事情,如测试本身.
10. 编辑:我不会在这个阶段使用TDD.根据定义,TDD将需要在更改到位之前进行所有测试,因此当您添加新的testSuite以覆盖您正在处理的类时,您将在整个地方进行失败的测试.而是添加新的testSuite,然后根据需要添加单个测试,这样您的测试结果中就不会出现大量噪声,导致测试失败.而且,正如Yishai指出的那样,在这个时间点添加学习TDD的任务将会让你失望.将学习TDD作为您有空余时间的任务.这并不困难.
11. 作为一个必然结果,你需要一个工具来跟踪testSuite存在的那些现有类,但是还没有编写测试来覆盖类中的其他成员函数.通过这种方式,您可以跟踪测试覆盖范围的漏洞.我在这里谈论的是一个高级别,你可以生成一个类列表和特定的成员函数,当前不存在任何测试.测试和testSuite的标准命名约定将极大地帮助您.

我想起他们会增加更多的积分.

HTH

Answer 2

您应该获得一份有效使用旧版代码的副本.这将为您提供有关如何将测试引入未编写的代码的良好指导.

TDD很棒,但您需要首先将现有代码置于测试之下,以确保您所做的更改在引入更改时不会更改现有的必需行为.

然而,现在引入TDD会让你在退回之前减慢很多,因为改造测试,即使只是在你正在改变的区域,在变得简单之前会变得复杂.

Answer 3

只是为了增加其他优秀的答案,我同意一次性从0%到100%的覆盖范围是不现实的 - 但是每次修复bug时都应该添加单元测试.

你说有很多错误和不满意的客户 - 我非常积极地将严格的TDD纳入错误修正过程,这比整体实现它要容易得多.毕竟,如果确实存在需要修复的错误,那么创建一个再现它的测试可以实现各种目标:

• 它可能是一个最小的测试用例,以证明确实存在问题
• 有信心(当前失败的)测试突出显示报告的问题,您将确定您的更改是否已修复它
• 它将永远作为回归测试,以防止将来再次出现同样的问题.

将测试引入现有项目很困难并且可能是一个漫长的过程,但是在修复错误的同时进行测试是一个理想的时间(与在"正常"意义上逐渐引入测试的同时)它会不要抓住机会,从你的错误报告中制作柠檬水,这是一种耻辱.:-)