相关疑难解决方法(0)

经过多年将Delphi程序编码为表单和数据模块中不可测试的代码(包括全局变量),唯一的类是表单本身,包含表单UI本身所需的所有代码.

我如何将代码转换为一组执行实际工作的类？我是否需要停止使用数据源/数据集并在类中执行所有操作？我需要ORM吗？

通常没有必要在表单中重用代码,所以将逻辑转换为类是否有意义？

背景 我在一个由7名开发人员和2名测试人员组成的团队中工作,这些团队负责物流系统.我们使用Delphi 2007和模拟驱动开发与Bold for Delphi作为框架.该系统现已投入生产约7年,拥有约1,700万行代码.我们在4-5周后发布到生产,几乎每次发布后我们都要为我们没有找到的bug做一些补丁.这对我们和客户来说当然都很烦人.

当前测试 解决方案当然是更自动化的测试.目前我们有手动测试.一个Testdbgenerator,以空数据库开头,并从建模方法中添加数据.我们还有Testcomplete,它运行一些非常基本的脚本来测试GUI.缺乏时间阻止我们添加更多测试,但脚本对应用程序中的更改也很敏感.几年前我真的尝试用DUnit进行单元测试,但是几天后我放弃了.这些单位的联系太紧.

单元测试前提条件 我认为我知道单元测试的一些前提条件:

• 编写做一件事的小方法,但做得好.
• 不要重复自己.
• 首先编写失败的测试,然后编写代码以便测试通过.
• 单位之间的联系是松散的.他们对彼此不太了解.
• 使用依赖注入.

使用的框架 我们可能会升级到Delphi XE2,主要是因为64位编译器.我看了一下Spring,但这需要D2007的更新,现在不会发生.或许明年.

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

编辑:关于手动测试的当前测试方法只是"敲打它并尝试打破它" 克里斯称之为.

我正在寻找有关构建Delphi程序以实现可维护性的一些建议.虽然我第一次学习使用Turbo Pascal进行编程,但是经过几十年的大部分C/C++后我才开始使用Delphi编程,所以我对基本语言并不感到不舒服.在我之前使用C++和C#的经历中,我通过使用cxxtest和NUnit成为了TDD转换器.

我继承了这个程序,我现在负责维护.它主要由表单和几个数据模块组成.应用程序业务逻辑和数据访问主要分散在表单中,而数据模块大多只是全局ADO对象生存的地方.数据库访问通常通过引用TADOQuery或TADOCommand的全局实例,将SQL文本格式化为对象的相关属性,并调用其Open或Execute方法来完成.

我试图将业务逻辑纳入一定程度的封装,可以进行单元测试.我已经看到了这个答案,就形式抽象逻辑而言,这是完全合理的.我想知道数据访问的最佳实践是什么.我的想法是数据模块应该公开一种特定于应用程序的迷你API(可能包含所有虚拟方法),以便可以用模拟对象替换它们进行测试.另一个答案的链接显示了一些让我相信自己走上正轨的例子,但我仍然有兴趣看到一些关于数据模块的最佳实践文档.我通过Google找到的大多数页面都提供了相同类型的例子,说明了你可以在设计时做的所有很酷的事情,将数据绑定控件连接到查询等等,我对此并不感兴趣.在这一刻.