跨越边界: 在集成框架中进行测试--在 Ruby on Rails 中进行单元测试

Hasana ·
更新时间:2024-11-13
· 865 次阅读

我还记得当我第一次得到自动测试的 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 在运行时之前都不会显露出来:

清单 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 环境中将看到一些示例。

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

在了解动态语言开发人员为什么这么热衷于测试之后,现在是构建一个需要一些真正测试的实际应用程序的时候了。

构建一个快速 Rails 应用程序

为了进展得快些,我采用了一个保存山地摩托车路线数据库的 Rails 应用程序。我将模型的几个测试放在一起。如果想和我一起编写代码,那么所有需要的工具是一个数据库引擎(我使用的是 MySQL)和 Ruby on Rails 1.1 或更新版本(请参阅 参考资料)。第一步是创建 Rails 项目。在命令提示符下输入 rails trails 命令,清单 2 显示了命令和结果:

清单 2. 构建 Rails 应用程序

  > rails trails create  create  app/controllers create  app/helpers create  app/models create  app/views/layouts

...partial results deleted...

create  test/fixtures create  test/functional create  test/integration create  test/mocks/development create  test/mocks/test create  test/unit create  test/test_helper.rb

...partial results deleted...

create  config/environment.rb create  config/environments/production.rb create  config/environments/development.rb create  config/environments/test.rb

...partial results deleted...

create  log/server.log create  log/production.log create  log/development.log create  log/test.log



ON 边界 行测 单元测试 rails Ruby 单元 测试 框架

需要 登录 后方可回复, 如果你还没有账号请 注册新账号