跨越边界: 在集成框架中进行测试，第1部分 - 编程入门网

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

捕获 bug

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

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 在运行时之前都不会显露出来 ：

清单 1. 带 bug 的 Ruby 代码

position = "2"　　　　　　　 #string, where a number was intended position = positoin + 4　　　#position is misspelled, evaluates to 0 puts "The position is:" + 　　　 position.to_string　　 #The method should be to_s

如果编译器能够捕捉 bug，那么这类 bug 解决起来是小菜一碟，但是如果依赖解释器，那么管理这些 bug 就困难得多。为了处理这些微妙的错误，动态语言的用户长期以来一直依赖于自动测试。在进行测试 的时候，比起其他语言，动态语言及其集成环境在一般意义和特殊意义上都具有显著的优势：

语言更简洁。测试基本上是脚本编程，许多最好的脚本语言都是动态类型化的。

集成环境支持的假设可以让集成测试更容易，也可能更强大。在 Rails 环境中将看到一些示例。

动态语言允许使用更松散的耦合，使一些测试格式更容易实现。

在了解动态语言开发人员为什么这么热衷于测试之后

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!