使用 Bold for Delphi 框架进行编码时提高可测试性

背景我在一个由 7 名开发人员和 2 名测试人员组成的团队中工作，负责物流系统。 我们使用 Delphi 2007 和模型驱动开发德尔福大胆 http://boldfordelphi.blogspot.com/作为框架。 该系统现已投入生产约 7 年，拥有约 170 万行代码。 我们在 4-5 周后发布到生产环境，几乎每次发布后，我们都必须针对我们没有发现的错误进行一些修补程序。这对我们和客户来说当然都是令人恼火的。

当前测试解决方案当然是更加自动化的测试。目前我们有手动测试。 Testdbgenerator 从空数据库开始，并从建模方法添加数据。我们还有测试完成 http://smartbear.com/products/qa-tools/automated-testing/它运行一些非常基本的脚本来测试 GUI。由于缺乏时间，我们无法添加更多测试，但脚本对应用程序中的更改也很敏感。几年前，我确实尝试过使用 DUnit 进行单元测试，但几天后我就放弃了。这些单位之间的联系太强。

单元测试前提条件我想我知道单元测试的一些先决条件：

• 编写只做一件事的小方法，但要把它做好。
• 不要重复自己。
• 首先编写失败的测试，然后编写代码以使测试通过。
• 各单元之间的连接应松动。他们应该对彼此了解不多。
• 使用依赖注入。

使用框架我们可能会升级到Delphi XE2，主要是因为64位编译器。 我看过Spring http://code.google.com/p/delphi-spring-framework/有点，但这需要从 D2007 进行更新，而现在不会发生。或许明年。

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

EDIT:关于手动测试的当前测试方法只是“重击它并尝试打破它”，如下所示Chris https://stackoverflow.com/users/289135/chris-thornton叫它。

你想要迈克尔·费瑟斯写的书，有效地处理遗留代码 https://rads.stackoverflow.com/amzn/click/com/0131177052。它展示了如何将（单元）测试引入到未考虑到可测试性而编写的代码中。

有些章节是根据开发人员可能为测试旧代码困难而给出的借口而命名的，并且它们包含案例研究和解决每个问题的建议方法：

• 我没有太多时间，我必须改变它
• 我无法在测试工具中运行此方法
• 这个班级太大了，我不想让它变得更大
• 我需要更改一个怪物方法，但我无法为其编写测试。

它还涵盖了许多打破依赖关系的技术；有些对您来说可能是新的，有些您可能已经知道但只是还没有想到使用。