跨越边界: 在集成框架中进行测试,第 1 部分

发表于:2008-06-25来源:作者:点击数: 标签:框架
捕获 bug 我还记得当我第一次得到 自动测试 的 bug 时的情况。在一次大会上,当我做完叫做 Bitter Java 的演讲之后,Mike Clark(Java 社区的自动测试大师, 性能 调整工具 JUnitPerf 的作者(请参阅 参考资料),现在是 Ruby on Rails 专家)走近我。Mike

捕获 bug

我还记得当我第一次得到自动测试的 bug 时的情况。在一次大会上,当我做完叫做 Bitter Java 的演讲之后,Mike Clark(Java 社区的自动测试大师,性能调整工具 JUnitPerf 的作者(请参阅 参考资料),现在是 Ruby on Rails 专家)走近我。Mike 告诉我有一种方法可以通过自动测试改进我的演讲。在那次大会的剩余时间里,我跟着他四处走,看到了我能看到的尽可能多的他的测试会议。我开始使用他推荐的技术,并对把红条(代表测试失败)变成绿条(代表测试通过)上了瘾。自动测试改变了我思考软件开发的方式。

 关于本系列

在 跨越边界 系列中,作者 Bruce Tate 提出了这样一个观点:如今的 Java 程序员可以通过学习其他方法和语言得到很好的其他思路。自从 Java 明显成为所有开发项目的最佳选择以来编程前景已经改变。其他的框架正影响构建 Java 框架的方式,从其他语言学到的概念可以影响您的 Java 编程。您编写的 Python(或 Ruby、Smalltalk ... )代码可以改变您处理 Java 编码的方式。

本系列为您介绍与 Java 开发根本不同,但也可以直接应用于 Java 开发的编程概念和技术。在一些例子中,需要对技术进行集成以利用它。在另外一些例子中,您将能够直接应用这些概念。单独的工具不及其他语言和框架能够影响 Java 社区中的开发人员、框架甚至基本方法的思想那么重要。
 
 
Java 社区绝对有自动测试的 bug。坦白地说,我们别无选择。竞争压力迫使许多公司编写越来越多的代码,而测试人员越来越少,同时每个开发人员的又必须有更高的生产率。如果不进行自动测试,得到测试的内容就会更少,面对现代应用程序不断增长的复杂性,较少的测试不是一个可行的选择方案。

在过去十年中,我们已经看到了对测试工具和技术的研究。JUnit 和 TestNG 都是支持自动单元测试的优秀工具,而且由日常的开发人员所驱动。Selenium 是改进集成和功能测试的工具。一套称作敏捷技术 的新开发过程告诉人们要更加重视自动测试,不要太多地依赖正式的设计工具,将它们作为提高质量的惟一工具。Java 社区已经走了很长的路。 (请参阅 参考资料,获得这里讨论的工具与技术的附加信息。)

其他编程社区也有 bug 工具, 其中一些社区使用的自动测试要比 Java 开发人员还有多,他们使用自动测试经验有完全不同的原因:

Smalltalk 程序员使用自动测试已经几乎有 30 年的时间了,所以通过动态类型化语言使用的一些技术更加先进。


集成框架的开发人员的优势是了解框架元素的结构和组合。有些框架,例如 Ruby on Rails,能够生成测试用例,而且在默认情况下提供测试特性。


具有高级元编程(metaprogramming)能力的语言,例如 Ruby and Lisp,允许使用其他语言不支持的一些测试技巧,例如更容易访问 mock 对象。
在这一篇和下一篇文章中,将全面理解在 Ruby on Rails 集成开发框架中的测试方式。第 1 部分侧重于测试模型对象,并提供一些从 Rails 获得启发的策略,可以用这些策略使 Java 单元测试更有效。第 2 部分把更多时间花在功能测试和集成测试上。作为 Java 程序员,您对一些概念可能比较熟悉,特别是在测试的时候,而其他一些概念可以拓展您的理解。

补漏

在这个系列的 前一期 中,了解了动态类型化会带来某些 bug 种类,静态类型化语言将在编译时捕捉到这些 bug。清单 1 的 Ruby 代码片段包含四个不同的 bug,这四个 bug 在运行时之前都不会显露出来:

原文转自:http://www.ltesting.net