提高可测试性，当使用Bold for Delphi框架编码时
Background我在一个由7名开发人员和2名测试人员组成的团队中工作，他们在一个物流系统上工作。我们使用Delphi2007和以Bold for Delphi为框架的模型驱动开发。该系统已投入生产约7年，拥有约170万行代码。我们在4-5周后发布到生产环境，几乎在每次发布之后，我们都必须为我们没有发现的bug做一些补丁。当然，这对我们和客户都很恼火。
Current testing解决方案当然更多的是自动化测试。目前我们有手动测试。一个测试数据库生成器，它从一个空数据库开始，并添加来自建模方法的数据。我们还有Testcomplete，它运行一些非常基本的脚本来测试图形用户界面。由于缺乏时间，我们无法添加更多的测试，但脚本对应用程序中的更改也很敏感。几年前，我真的尝试过使用DUnit进行单元测试，但几天后我就放弃了。这些单元的连接太强了。
单元测试的先决条件我想我知道一些单元测试的先决条件：
yourself.
- First
- 写小方法做一件事，但做得好。
- 不要重复写失败的测试，然后写代码，这样测试就通过了。
- 单元之间的连接应该是松散的。它们不应该相互了解太多。
- 使用依赖注入。
使用Delphi框架我们可能会升级到 XE2，主要是因为64位编译器。我已经研究了一下Spring，但这需要D2007进行更新，现在不会发生这种情况。也许明年吧。
The still 大多数代码仍然没有自动测试。那么，提高旧代码可测试性的最佳途径是什么呢？或者，最好开始只为新方法编写测试？我不确定增加自动化测试的最好方法是什么，欢迎对其发表评论。我们现在可以使用D2007 + DUnit吗?以后可以轻松地切换到Delphi XE2 + Spring吗？
编辑:关于当前手动测试方法的，正如Chris所说的那样，只是“猛击它并试图打破它”。
回答 3
Stack Overflow用户
发布于 2011-10-14 02:08:57
你想要迈克尔·费瑟斯写的书吗，。它展示了如何向没有考虑可测试性的代码引入(单元)测试。
其中一些章节是以开发人员可能给出的为什么测试旧代码很难的借口命名的，它们包含案例研究和解决每个问题的建议方法：
- 我没有太多时间，我必须更改它
- 我无法在测试工具中运行此方法
- 此类太大，我不希望它获得更大的
- 我需要更改怪物方法，并且我无法为其编写测试。
它还介绍了许多打破依赖关系的技术；有些对您来说可能是新的，有些您可能已经知道了，但还没有想过要使用。
Stack Overflow用户
发布于 2011-10-13 05:31:36
自动化单元测试的需求是这样的：
- 使用单元测试框架(例如，DUnit)。
- 使用某种模拟框架。
第二项是最难的。
干，小方法，从测试开始，DI都是糖。首先，您需要开始单元测试。边走边加干的，等等。减少耦合有助于使内容更容易进行单元测试，但如果没有巨大的重构工作，您将永远不会减少现有代码库中的耦合。
考虑为新的东西和在版本中发生变化的东西编写测试。随着时间的推移，您将获得一个合理的单元测试基础。新的和变化的东西也可以被重构(或者写得很好)。
此外，请考虑运行单元测试并在构建中断时发送电子邮件的自动构建过程。
这只涵盖了单元测试。对于QA测试人员，您需要一个允许他们运行自动化测试(不是单元测试)的工具(他们确实存在，但我想不出有什么工具)。
Stack Overflow用户
发布于 2011-10-13 05:00:44
你的测试团队太小了，IMO。我曾经在QA部门人数超过开发人员的团队中工作过。考虑在适合较小周期的可管理块(特性、修复)的“冲刺”中工作。“敏捷”将鼓励两周的冲刺，但这可能太紧了。无论如何，这将使QA不断忙碌，在发布窗口之前工作得更远。现在，我怀疑他们是空闲的，直到你给他们大量的代码，然后他们就被淹没了。使用较短的发布周期，您可以让更多的测试人员忙碌起来。
此外，您也没有过多地谈到他们的测试方法。他们有没有运行的标准脚本，用来对照预期的外观和行为来验证外观和行为？或者他们只是“猛击它，并试图打破它”？
在IMO中，数据单元测试很难处理许多依赖项，如数据库、通信等。但这是可行的。我已经创建了自动运行数据库设置脚本的DUnit类(查找与被测试类同名的.sql文件，运行sql，然后继续测试)，它非常有效。对于SOAP通信，我有一个运行的SoapUI模拟服务，它返回录制的结果，所以我可以测试我的通信。
这确实需要付出努力，但这是值得的。
https://stackoverflow.com/questions/7745463
复制相似问题