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

Question

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

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

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

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

使用的框架 我们可能会升级到Delphi XE2，主要是因为64位编译器。 我稍微研究了一下 Spring 但这需要从 D2007 进行更新并且现在这种情况不会发生。也许明年。

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

编辑：关于手动测试的当前测试方法只是“重击并尝试打破它”，如 克里斯称之为。

Answer 1

您想要 Michael Feathers 所著的书，有效地使用旧代码< /a>.它展示了如何向未考虑到可测试性而编写的代码引入（单元）测试。

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

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

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

Answer 2

自动化单元测试的要求正是这样：

1. 使用单元测试框架（例如DUnit）。
2. 使用某种模拟框架。

第 2 项是最难的一项。

DRY，小方法，从测试开始，DI都是糖。首先您需要开始单元测试。边做边添加 DRY 等。减少耦合有助于使内容更容易进行单元测试，但如果不进行巨大的重构工作，您将永远无法减少现有代码库中的耦合。

考虑为新的内容和版本中更改的内容编写测试。随着时间的推移，您将获得合理的单元测试基础。新的和变化的东西也可以被重构（或写得很好）。

另外，请考虑一个自动构建过程，该过程运行单元测试并在构建中断时发送电子邮件。

这仅涵盖单元测试。对于 QA 测试人员，您将需要一个工具（它们存在，但我想不出任何工具）来允许他们运行自动化测试（不是单元测试）。

Answer 3

在我看来，你的测试团队太小了。我曾经工作过的团队中，质量检查部门的数量超过了开发人员的数量。考虑在适合较小周期的可管理块（功能、修复）的“冲刺”中工作。 “敏捷”会鼓励两周的冲刺，但这可能太紧了。不管怎样，这会让 QA 持续忙碌，在发布窗口之前工作得更远。现在，我怀疑他们是闲置的，直到你给他们大量的代码，然后他们就会被淹没。随着发布周期的缩短，您可以让更多的测试人员忙碌起来。

另外，您没有过多谈论他们的测试方法。他们是否有运行的标准脚本，根据预期的外观和行为来验证外观和行为？或者他们只是“猛击它并试图打破它”？

IMO，Dunit 测试很难因为数据库、通信等大量依赖项而进行。但它是可行的。我创建了自动运行数据库设置脚本的 DUnit 类（查找与正在测试的类同名的 .sql 文件，运行 sql，然后继续测试），并且非常有效。对于 SOAP 通信，我运行了一个 SoapUI 模拟服务，该服务返回预设结果，因此我可以测试我的通信。
这确实需要工作，但这是值得的。