ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 测试:开发人员理想与现实的大PK

测试:开发人员理想与现实的大PK

原创 Linux操作系统 作者:agile_boy 时间:2009-03-11 13:06:14 0 删除 编辑

PDC大会上进行了关于“单元测试的未来”的小组讨论,大部分的谈话内容聚焦于Mock测试,人们对于Mock 框架(Mock frameworks)的过度使用取得了普遍共识。

共识如下:通常,实现所有必要的接口非常无聊,而且消耗时间。为了更方便,人们选择了Mock 框架。但这遮盖了更本质的问题:API被设计得过于复杂。

关于“开发人员测试”与其他人员的测试之间的区别,有一个热门的话题。一直以来的讨论中,人们都认为开发人员只需要做单元测试,而需求测试、验收测试、集成测试,以及所有其他形式的测试都是其他人的工作。

这里强调了在单元测试社区中存在的一个普遍误解。具体来说,就是假设所有开发人员都配备了QA团队,以处理所有其他类型的测试。不幸的是,即使是拥有数百万资金的公司也往往根本没有QA资源,所有的测试都留给了开发人员和最终用户。

开发人员无法进行更多类型测试的主要原因是速度。 单元测试已经太慢了,因此没有更多时间去进行那些更慢的测试了,比如包括网络通信的测试。 遗憾的是,并没有人考虑其他变通之策。

举个例子,单元测试框架其实可以更加智能,它们可以使用代码覆盖率的结果,只对发生变化的代码进行二次测试。一个类的变化,不应该触发重新运行所有的测试集合。所谓“单元测试”意味着你只需测试一个小的子集即可。

另外一种没有被提及的改进是利用分布式编程。代码和测试可以被快速上传到各个服务器并且得到执行。通过引入持续集成,我们已经拥有了所有需要的技术。

早些的讨论普遍觉得数据库方面被忽视了,大部分的数据库开发人员很少或几乎没有单元测试的概念,也缺乏相关支持工具。更可怕的是,他们甚至都没有被邀请来参加讨论。遗憾的是这就是目前的现状。讨论中也没有提供方法改善这些现实问题。

从好的方面看,已经有一些人在讨论使用建模工具来让单元测试更加简单。他们提供了很多可选的办法,例如从定义契约级别开始。这些契约可以被代码生成器用来编写实际的测试代码。显然,这并非一个100%完美的解决方案,但它能够减少经常遇到的困难。

另一个被看好的办法是采用delta状态管理。设想测试“取钱”这个功能,很多人会假设被测试帐户最开始有100美元,经过交易后,剩下80美元。这个方法就是首先查询一下账号余额,然后再看是否减少了20美元。这样一来,就不必在每次运行测试时都重新设置测试环境了。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14639675/viewspace-566786/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 裁员下的敏捷
请登录后发表评论 登录
全部评论

注册时间:2008-07-01

  • 博文量
    120
  • 访问量
    118184