这里描述了系统是如何进行工作的:你在电脑上编写代码,直到你确信已经完成了某个功能或者修补了某个缺陷,然后你将所作的修改提交到源代码管理系统中 (SCM)。持续集成系统一直监视着SCM,注意到该段代码发生了改变。接着,它就会从SCM中检出代码,构建它,并且运行整个测试。你也将会及时地收到 一封邮件,通知修改和测试是否已经通过或者失败。
这个概念相当简单,但是它在实践中力量非凡。
测试
BAT最后一部分就是指自动测试。现在CI系统正在构建产品,运行你的自动测试,我们需要确信我们的测试充分地覆盖了整个产品。毕竟,从客户的观点来看,如果一个测试不能检验客户所使用的功能,那它就是没用的。
首先,设法理解产品是如何使用的……对于一个遗留产品,这常常是出于自身的要求。或许,你甚至要为客户创建一套使用场景。例如,恐怕你要有一组场景,生成日常的报表,完成日常的数据导入,或者增加新的客户。
或许,你也想区分用户类别,它被称为“用户角色”。你恐怕要有“Joe——超级用户”、“Mary——系统管理员”或者“Fred——新用户”等用户角色。每个角色使用了该产品中不同的功能,正如一个超级用户与一个新手使用该产品是大相径庭的。
下一步就是使用模拟客户测试来重现大多数的普通客户使用场景。
模拟客户测试
模拟客户测试(Mock Client Test)并不是一套特定的测试框架。它的目的是用来确保预期的功能不会被破坏。你要改变系统中的一部分,却不知道这个修改影响了产品的其他区域,这在遗 留产品中经常出现。曾经我编写一个产品时,修改了通讯协议,却影响了GUI组件布局。CI系统中的模拟客户测试,是你预防意外修改的保障策略。对产品是否 如你所预望进行测试,就会有一个坚实的产品基线。而且测试也会包括更多有趣的情形,正如你所遇到的那样。
一个优秀的测试策略是缺陷驱动测 试(Defect Driven Testing)。每次你发现一个系统缺陷,就增加一个相应的测试。当你增加该个测试时,你可以尝试增加一些与该测试相近而不同的测试。随着时间的推移, 这个策略为产品最需要涵盖的范围,提供了相当可观的测试覆盖率。
不管你如何选择增加测试,都要设置测试优先级。如果你计划对产品进行任何修改,有一个基本的测试套件是最关键的。
最后一步就是将测试集成到持续集成系统。
当自动测试运行在持续集成环境下时,你会及时地得到关于所有问题的反馈。每次你修改一段代码,你就会“从头开始”构建和运行完整的测试。大多数开发者很快就会沉浸于此,并且很快依赖这个 “编外成员”。
● 编写场景
● 创建模拟客户测试
● 使用持续集成
小结
构建、自动化和测试(BAT)对于程序员都是好的建议,但是它对于继承遗留代码者尤其好。拥有自信的重构能力非常关键。我发现如果我要不断地停 下来去查看我正在破坏什么,这种境况下变得高效则很困难。一个好的测试套件可以替我进行监视,而且能够让我集中精力设法完成性能改进。
记住,如果你不能测试遗留代码的话,那么就不要修改它。而且不要单纯地进行手动测试,除非没有其他选择。
不仅不要害怕遗留代码,还要正确地对待它。用BAT这种方法来处理它,你就会每次都能成功。