当使用Bold编写Delphi框架时,提高可测试性

Question

背景 我在一个由7名开发人员和2名测试人员组成的团队中工作,这些团队负责物流系统.我们使用Delphi 2007和模拟驱动开发与Bold for Delphi作为框架.该系统现已投入生产约7年,拥有约1,700万行代码.我们在4-5周后发布到生产,几乎每次发布后我们都要为我们没有找到的bug做一些补丁.这对我们和客户来说当然都很烦人.

当前测试 解决方案当然是更自动化的测试.目前我们有手动测试.一个Testdbgenerator,以空数据库开头,并从建模方法中添加数据.我们还有Testcomplete,它运行一些非常基本的脚本来测试GUI.缺乏时间阻止我们添加更多测试,但脚本对应用程序中的更改也很敏感.几年前我真的尝试用DUnit进行单元测试,但是几天后我放弃了.这些单位的联系太紧.

单元测试前提条件 我认为我知道单元测试的一些前提条件:

• 编写做一件事的小方法,但做得好.
• 不要重复自己.
• 首先编写失败的测试,然后编写代码以便测试通过.
• 单位之间的联系是松散的.他们对彼此不太了解.
• 使用依赖注入.

使用的框架 我们可能会升级到Delphi XE2,主要是因为64位编译器.我看了一下Spring,但这需要D2007的更新,现在不会发生.或许明年.

问题 大多数代码仍然没有自动测试.那么提高旧代码可测试性的最佳途径是什么？或者也许最好只开始为新方法编写测试？我不确定增加自动测试的最佳方法是什么,欢迎提出意见.我们现在可以使用D2007 + DUnit,然后轻松更改为Delphi XE2 + Spring吗？

编辑:关于手动测试的当前测试方法只是"敲打它并尝试打破它" 克里斯称之为.

Answer 1

你想要Michael Feathers的书,有效地使用遗留代码.它展示了如何将(单元)测试引入到未编写可测试性的代码中.

有些章节是以开发人员为可能给出的为什么测试旧代码很难找到的借口而命名的,它们包含案例研究并提出解决每个问题的方法:

• 我没有太多时间,我必须改变它
• 我无法在测试工具中运行此方法
• 这个课程太大了,我不希望它变得更大
• 我需要改变一个怪物方法,我不能为它编写测试.

它还涵盖了许多打破依赖关系的技术; 有些可能对你来说是新的,有些你可能已经知道但是还没想过要用.