单元测试 – 使用Delphi框架的Bold编码时,可以提高可测性

前端之家收集整理的这篇文章主要介绍了单元测试 – 使用Delphi框架的Bold编码时,可以提高可测性前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
背景
我在7名开发人员和2名在物流系统上工作的测试人员的团队工作。
我们使用Delphi 2007和modeldriven开发与 Bold for Delphi作为框架。
该系统目前已经生产了大约7年,拥有大约1,700万行的代码
我们在4-5周后才能发布,几乎每次发布之后,我们都要做一些我们没有找到的bug的补丁。这对我们和客户来说当然是令人不安的。

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

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

写一些做一件事的小方法,但做得很好。
>不要重复你自己。
>首先写出失败的测试,然后写代码,以便测试通过。
>单位之间的连接松动。他们不应该彼此了解太多。
>使用依赖注入。

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

问题
大多数代码仍然没有自动测试。那么为了提高旧代码的可测试性,最好的途径是什么?或者最好是开始为新方法编写测试?
我不知道什么是增加自动测试和评论的最佳方式是欢迎。我们现在可以使用D2007 DUnit,然后很容易地更改为Delphi XE2 Spring?

编辑:关于手动测试的现行测试方法,就像Chris所说的那样,只是“打破它,试图打破它”。

解决方法

你想要这本书,由Michael Feathers, Working Effectively with Legacy Code.它显示了如何引入(单元)测试代码,没有写入可测试性。

一些章节被命名为开发人员为什么要测试旧代码是困难的借口,它们包含案例研究和建议的方法解决每个问题:

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

它还涵盖了许多破坏依赖的技术;有些可能对你来说是新的,有些你可能已经知道,但是还没有想过使用。

猜你在找的Delphi相关文章