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

Question

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

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

单元测试先决条件我想我知道单元测试的一些先决条件:

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

要使用的框架我们可能会升级到Delphi XE2，主要是因为64位编译器。我看过Spring有点，但这需要从 D2007 进行更新，而现在不会发生。也许明年。

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

编辑:关于手动测试的当前测试方法只是“重击它并尝试打破它”，如 Chris调用它。

Answer 1

您想要迈克尔·费瑟斯 (Michael Feathers) 的书，Working Effectively with Legacy Code 。它展示了如何向未考虑到可测试性而编写的代码引入(单元)测试。

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

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

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