问提高可测试性，当使用Bold for Delphi框架编码时

EN

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所说的那样，只是“猛击它并试图打破它”。