精通 Grails: 测试 Grails 应用程序

排除 bug,构建可执行文档

Grails 可以轻松确保您的应用程序从始至终都远离 bug。这还有另一个好处,您可以利用测试代码生成一组通常是最新的可执行文档。本月 Grails 专家 Scott Davis 向您展示如何对 Grails 进行测试。

Scott Davis , 主编, AboutGroovy.com

Scott Davis 是国际知名作家、演讲家和软件开发人员。他出版的书籍包括 Groovy Recipes: Greasing the Wheels of JavaGIS for Web Developers: Adding Where to Your ApplicationThe Google Maps APIJBoss At Work



2008 年 10 月 31 日

我是测试驱动开发(test-driven development,TDD)的大力支持者。Neal Ford(The Productive Programmer 的作者)说道 “不测试所编写的代码就是失职”。Michael Feathers(Working Effectively with Legacy Code 的作者)将 “遗留代码” 定义为没有经过相应测试的任何软件 — 这表明编写代码而不进行测试是一种过时的实践。我常说每编写一定数量的生产代码,就要编写两倍的测试代码。

精通 Grails 尚未讨论 TDD,因为到目前为止,这个系列主要关注如何利用 Grails 的核心功能。测试基础设施代码(不用您编写的代码)有一定的价值,但我很少这样做。我相信 Grails 能够正确地将我的 POGO 呈现为 XML,或在我调用 trip.save() 时将我的 Trip 保存到数据库。当您检查自己编写的代码时,测试的真正价值就体现出来了。如果您编写一个复杂的算法,您应该有一个或多个补充单元测试,确保该算法正常工作。在本文,您将看到 Grails 如何帮助和鼓励您进行应用程序测试。

编写第一个测试

在开始测试之前,我将介绍一个新的域类。这个类的一些定制功能必须经过测试才能进入到生产中。输入 grails create-domain-class HotelStay,如清单 1 所示:

关于本系列

Grails 是一种新型 Web 开发框架,它将常见的 Spring 和 Hibernate 等 Java™ 技术与当前流行的约定优于配置等实践相结合。Grails 是用 Groovy 编写的,它可以提供与遗留 Java 代码的无缝集成,同时还可以加入脚本编制语言的灵活性和动态性。学习完 Grails 之后,您将彻底改变看待 Web 开发的方式。

清单 1. 创建 HotelStay
$ grails create-domain-class HotelStay

Environment set to development
     [copy] Copying 1 file to /src/trip-planner2/grails-app/domain
Created Domain Class for HotelStay
     [copy] Copying 1 file to /src/trip-planner2/test/integration
Created Tests for HotelStay

从清单 1 可以看到,Grails 在 grails-app/domain 目录中为您创建了一个空的域类。它还在 test/integration 目录中创建了一个带有空的 testSomething() 方法的 GroovyTestCase 类(稍后我将进一步讲述单元测试和集成测试的区别)。清单 2 展示了一个带有生成的测试的空 HotelStay 类:

清单 2. 带有生成的测试的空类
class HotelStay {
}

class HotelStayTests extends GroovyTestCase {
    void testSomething() {
    }
}

GroovyTestCase 是在 JUnit 3.x 单元测试之上的一层 Groovy。如果您熟悉 JUnit TestCase,您肯定知道 GroovyTestCase 是如何工作的。对于这两种情况,您通过断言代码正常工作来测试它们。JUnit 有各种不同的断言方法,包括 assertEqualsassertTrueassertNull 等等。它使您通过编程的方式表明 “我断言这个代码按照预期工作”。

为什么是 JUnit 3.x 而不是 4.x?

由于历史原因,GroovyTestCase 就是一个 JUnit 3.x TestCase。当 Groovy 1.0 于 2007 年 1 月发布时,它支持 Java 1.4 语言结构。它可以在 Java 1.4、1.5 和 1.6 JVM 上运行,但在语言级别上仅与 Java 1.4 兼容。

接下来 Groovy 的主要发布版是 1.5,在 2008 年 1 月发布。Groovy 1.5 支持所有 Java 1.5 语言特性,比如泛型、静态导入、for/in 循环和注释(后者最值得讨论)。不过 Groovy 1.5 仍然可以在 Java 1.4 JVM 上运行。Groovy 开发团队许诺所有 Groovy 1.x 版本都将与 Java 1.4 保持向后兼容性。当 Groovy 2.x 发布时(可能是 2009 年末或 2010 年),它将不支持 Java 1.4。

因此,这些与 GroovyTestCase 打包的 JUnit 版本有什么关系呢?JUnit 4.x 引入了一些注释,比如 @test@before@after。尽管这些新特性非常有趣,但 JUnit 3.x 仍然是 GroovyTestCase 向后兼容 Java 1.4 的基础。

这就是说,您完全可以使用 JUnit 4.x(参见 参考资料 获得 Groovy 站点相关文档的链接)。引入其他使用注释和 Java 5 语言特性的测试框架是完全有可能的(参见 参考资料 获得结合使用 TestNG 和 Groovy 的示例)。Groovy 的字节码与 Java 编程兼容,因此您可以通过 Groovy 使用任何 Java 测试框架。

将清单 3 中的代码添加到 grails-app/domain/HotelStay.groovy 和 test/integration/HotelStayTests.groovy:

清单 3. 一个简单的测试
class HotelStay{
  String hotel
}

class HotelStayTests extends GroovyTestCase {
  void testSomething(){
    HotelStay hs = new HotelStay(hotel:"Sheraton")
    assertEquals "Sheraton", hs.hotel
  }
}

清单 3 正是我前面提到那种低级 Grails 基础设施测试。您应该相信 Grails 能够正确执行这个操作,因此这是一个典型的错误测试类型。但它允许您编写最简单的测试并观察其运行,实现了本文的目的。

要运行所有测试,请输入 grails test-app。要仅运行这个测试,请输入 grails test-app HotelStay(由于约定优于配置,Tests 后缀可以省略)。不管输入哪个命令,您应该会在命令提示中看到如清单 4 所示的输出(注意:为了突出重要的特性,我删减了许多代码)。

清单 4. 运行测试时的输出
$ grails test-app
Environment set to test

No tests found in test/unit to execute ...

-------------------------------------------------------
Running 1 Integration Test...
Running test HotelStayTests...
                    testSomething...SUCCESS
Integration Tests Completed in 253ms
-------------------------------------------------------

Tests passed. View reports in /src/trip-planner2/test/reports

这里发生了 4 件重要的事情:

  1. 可以看到,environment 被设置为 test。这意味着 conf/DataSource.groovy 文件中的 test 块的数据库设置已生效。
  2. test/unit 中的脚本已运行。您尚未编写任何单元测试,所以不能找到任何单元测试,这并不奇怪。
  3. test/integration 中的脚本已经运行。您可以看到 HotelStayTests.groovy 脚本的输出 — 它的旁边有个很大的 SUCCESS
  4. 这个脚本向您展示一组报告。

如果您在 Web 浏览器中打开 /src/trip-planner2/test/reports/html/index.html,应该会看到一个关于所有已运行的测试的报告。如图 1 所示。

图 1. JUnit 顶级汇总报告
JUnit 顶级汇总报告

如果您单击 HotelStayTests 链接,应该会看到 doSomething() 测试,如图 2 所示:

图 2. JUnit 类级报告
JUnit 类级报告

如果测试意外失败,命令提示输出和 HTML 报告(如图 3 所示) 将通知您:

图 3. 失败的 JUnit 测试
失败的 JUnit 测试

编写第一个有价值的测试

以上是第一个正常运行的简单测试,接下来将展示一个更加实用的 测试示例。假设您的 HotelStay 类有两个字段:Date checkInDate checkOut。根据一个用户情景,toString 方法的输出应该像这样:Hilton (Wednesday to Sunday)。通过 java.text.SimpleDateFormat 类,获取正确格式的日期非常简单。您应该为此编写一个测试,但不需验证 SimpleDateFormat 是否正确工作。您的测试做两件事情:它验证 toString 方法是否按照预期运行;它证明您是否满足用户情景。

单元测试是可执行的文档

用户需求常常是桌面上的某些文档。作为开发人员,您应该将这些需求转换成有效的软件。

需求文档的问题是:在进行实际软件开发时它通常已经过时。它不是可以随着软件的发展而变化的 “活动文档”。工件 一词完美地描述了这种情况 — 文档描述软件最初的、历史性的任务是什么,而不是当前实现要做什么。

要想准备一组全面的、优秀的测试,仅仅保持代码没有 bug 是不够的。这样的测试有一个附带的好处,即您可以得到 “可执行的文档”:用代码表示活动的、不断变化的项目需求。如果将测试映射到需求,则可以和用户共享某些内容。您必须保证代码的健全,保证满足了用户的需求。将这个可执行文档与 CruiseControl 等持续集成服务器(持续反复地运行测试的服务器)相结合,就可以得到一个安全保障机制,它保证新特性不会对原本良好的软件造成损害。

行为驱动的开发(Behavior-Driven Development,BDD)完全采用了可执行文档的想法。easyb 是一个用 Groovy 编写的 BDD,它允许您将测试编写成用户和开发人员都可以阅读的用户需求(参见 参考资料)。如果一些用户思想比较前卫,宁愿放弃 Microsoft® Word(例如),easyb 可以排除所有过时的需求文档。因此,项目需求从一开始就是可执行的。

将清单 5 中的代码输入到 HotelStay.groovy 和 HotelStayTests.groovy:

清单 5. 使用 assertToString
import java.text.SimpleDateFormat
class HotelStay {
  String hotel
  Date checkIn
  Date checkOut
   
  String toString(){
    def sdf = new SimpleDateFormat("EEEE")
    "${hotel} (${sdf.format(checkIn)} to ${sdf.format(checkOut)})"
  }  
}


import java.text.SimpleDateFormat
class HotelStayTests extends GroovyTestCase {

    void testSomething(){...}

    void testToString() {
      def h = new HotelStay(hotel:"Hilton")
      def df = new SimpleDateFormat("MM/dd/yyyy")
      h.checkIn = df.parse("10/1/2008")
      h.checkOut = df.parse("10/5/2008")
      println h
      assertToString h, "Hilton (Wednesday to Sunday)"
    }
}

输入 grails test-app 验证第二个测试是否通过。

testToString 方法使用了新的断言方法之一 —assertToString— 它由 GroovyTestCase 引入。使用 JUnit assertEquals 方法肯定会获得相同的结果,但是 assertToString 的表达能力更强。测试方法的名称和最终的断言清楚地表明了这个测试的目的(参见 参考资料 获得一个链接,它列出了 GroovyTestCase 支持的所有断言,包括 assertArrayEqualsassertContainsassertLength)。


添加控制器和视图

到目前为止,您一直以编程的方式与 HotelStay 域类交互。添加一个 HotelStayController,如清单 6 所示,它使您能够在 Web 浏览器上使用该类:

清单 6. HotelStayController 源代码
class HotelStayController {
  def scaffold = HotelStay
}

您应该对 create 表单进行仔细的 UI 调试。默认情况下,日期字段包括 day、month、year、hours 和 minutes,如图 4 所示:

图 4. 默认显示日期和时间
默认显示日期和时间

在这里,忽略日期字段的时间戳部分是安全的。输入 grails generate-views HotelStay。要创建图 5 所示的经过修改的 UI,请将 precision="day" 添加到 views/hotelStay/create.gsp 和 views/hotelStay/edit.gsp 中的 <g:datePicker> 元素:

图 5. 仅显示日期
仅显示日期

有了运行在 servlet 容器中的活动的、有效的 HotelStay 之后,就要开始讨论测试了:单元测试还是集成测试?


对比单元测试和集成测试

如我前面所述,Grails 支持两种基本类型的测试:单元测试和集成测试。这两者之间没有语法区别 — 它们都是用相同的断言写的 GroovyTestCase。它们的区别在于语义。单元测试孤立地测试类,而集成测试在一个完整的运行环境中测试类。

坦白地说,如果您想将所有的 Grails 测试都编写成集成测试,则刚好符合我的想法。所有 Grails create-* 命令都生成相应的集成测试,所以很多人都使用现成的集成测试。正如稍后看到的一样,很多测试需要在完整的运行环境中进行,因此默认使用集成测试是很好的选择。

如果您想测试一些非核心 Grails 类,则适合使用单元测试。要创建一个单元测试,请输入 grails create-unit-test MyTestUnit。因为测试脚本不是在不同的包中创建的,所以单元测试和集成测试的名称应该是惟一的。如果不是这样的话,将会收到清单 7 所示的错误消息:

清单 7. 单元测试和集成测试同名时收到的错误消息
The sources 
/src/trip-planner2/test/integration/HotelStayTests.groovy and 
   /src/trip-planner2/test/unit/HotelStayTests.groovy are 
   containing both a class of the name HotelStayTests.
 @ line 3, column 1.
   class HotelStayTests extends GroovyTestCase {
   ^

1 error

因为集成测试默认使用后缀 Tests,所以我在所有单元测试上都使用后缀 UnitTests,避免混淆。


为简单的验证错误消息编写测试

下一个用户场景说明 hotel 字段不能留空。这很容易通过内置的 Grails 验证框架来实现。将一个 static constraints 块添加到 HotelStay,如清单 8 所示:

清单 8. 将一个 static constraints 块添加到 HotelStay
class HotelStay {
  static constraints = {
    hotel(blank:false)
    checkIn()
    checkOut()
  }
  
  String hotel
  Date checkIn
  Date checkOut
  
  //the rest of the class remains the same
}

输入 grails run-app。如果您尝试在留空 hotel 字段的情况下创建一个 HotelStay,将收到如图 6 所示的错误消息:

图 6. 空字段的默认错误消息
空字段的默认错误消息

我敢保证您的用户会喜欢这个特性,但对默认的错误消息还不是很满意。假设他们稍微改动了一下用户场景:hotel 字段不能留空;如果留空,错误消息会提示 “Please provide a hotel name”。

现在您已经添加了一些定制代码 — 尽管它就像一个定制的 String 那么简单 — 接下来应该添加测试了(当然,编写一个验证用户场景的完整性的测试 — 尽管不涉及到定制代码 — 也是完全可以接受的。

打开 grails-app/i18n/messages.properties 并添加 hotelStay.hotel.blank=Please provide a hotel name。尝试在浏览器中提交一个空 hotel。这时您将看到自己的定制消息,如图 7 所示:

图 7. 显示定制的验证错误消息
显示定制的验证错误消息

向 HotelStayTests.groovy 添加一个新测试,检验对空字段的验证是否有效,如清单 9 所示:

清单 9. 测试验证错误
class HotelStayTests extends GroovyTestCase {
  void testBlankHotel(){
    def h = new HotelStay(hotel:"")
    assertFalse "there should be errors", h.validate()
    assertTrue "another way to check for errors after you call validate()", h.hasErrors()
  }

  //the rest of the tests remain unchanged
}

在生成的控制器中,您已经看到添加到域类中的 save() 方法。在这里,我本来也可以调用 save(),但事实上我并不想把新的类保存到数据库。我只关注验证是否发生。由 validate() 方法来完成这个任务。如果验证失败,则返回 false。如验证成功,则返回 true

hasErrors() 是另一个很有价值的测试方法。在调用 save()validate() 之后,hasErrors() 允许您查看验证错误。

清单 10 是经过扩展的 testBlankHotel(),它引入了其他一些很有用的验证方法:

清单 10. 验证错误的高级测试
class HotelStayTests extends GroovyTestCase {
  void testBlankHotel(){
   def h = new HotelStay(hotel:"")
   assertFalse "there should be errors", h.validate()
   assertTrue "another way to check for errors after you call validate()", h.hasErrors()  
  
   println "\nErrors:"
   println h.errors ?: "no errors found"   
     
   def badField = h.errors.getFieldError('hotel') 
   println "\nBadField:"
   println badField ?: "hotel wasn't a bad field"
   assertNotNull "I'm expecting to find an error on the hotel field", badField


   def code = badField?.codes.find {it == 'hotelStay.hotel.blank'} 
   println "\nCode:"
   println code ?: "the blank hotel code wasn't found"
   assertNotNull "the blank hotel field should be the culprit", code
  }
}

确定类没有通过验证之后,您可以调用 getErrors() 方法(在这里,借助 Groovy 简洁的 getter 语法,它被缩略为 errors),返回一个 org.springframework.validation.BeanPropertyBindingResult。就像 GORM 与 Hibernate 相比是一个瘦 Groovy 层一样,Grails 验证只不过是一个简单的 Spring 验证。

调用 println 的结果不会在命令行上显示,但它们出现在 HTML 报告中,如图 8 所示:

图 8. 查看测试的 println 输出
查看测试的 println 输出

HotelStayTests 报告的右下角单击 System.out 链接。

清单 10 中给人亲切感觉的 Elvis 操作符(转过脸来 — 看见他向后梳起的发型和那双眼睛吗?)是一个缩略的 Groovy 三元操作符。如果 ?: 左边的对象为 null,将使用右边的值。

将 hotel 字段更改为 "Holiday Inn" 并重新运行测试。您将在 HTML 报告中看到另一个 Elvis 输出,如图 9 所示:

图 9. 测试输出中的 Elvis
测试输出中的 Elvis

看见 Elvis 之后,不要忘记清空 hotel 字段 — 如果您不希望留下中断的测试的话。

如果仍然显示关于 checkIncheckOut 的验证错误,您不必担心。就这个测试而言,您完全可以忽略它们。但是这表明您不应该仅测试错误是否出现 — 您应该确保特定的 错误被抛出。

注意,我没有断言定制错误消息的确切文本。为什么我上一次关注匹配的字符串(测试 toString 的输出时)而这一次没有关注?toString 方法的定制输出便是上一个测试的目的。这一次,我更关心的是确定验证代码的执行,而不是 Grails 是否正确呈现消息。这表明测试更像一门艺术,而不是科学(如果我想验证准确的消息输出,则应该使用 Web 层测试工具,比如 Canoo WebTest 或 ThoughtWorks Selenium)。


创建和测试定制验证

现在,应该处理下一个用户场景了。您需要确保 checkOut 日期发生在 checkIn 日期之后。要解决这个问题,您需要编写一个定制验证。编写完之后,要验证它。

将清单 11 中的定制验证代码添加到 static constraints 块:

清单 11. 一个定制的验证
class HotelStay {
  static constraints = {
    hotel(blank:false)
    checkIn()
    checkOut(validator:{val, obj->
      return val.after(obj.checkIn)
    })
  }
  
  //the rest of the class remains the same
}

val 变量是当前的字段。obj 变量表示当前的 HotelStay 实例。Groovy 将 before()after() 方法添加到所有 Date 对象,所以这个验证仅返回 after() 方法调用的结果。如果 checkOut 发生在 checkIn 之后,验证返回 true。否则,它返回 false 并触发一个错误。

现在,输入 grails run-app。确保不能创建一个 checkOut 日期早于 checkIn 日期的新 HotelStay 实例。如图 10 所示:

图 10. 默认的定制验证错误消息
默认的定制验证错误消息

打开 grails-app/i18n/messages.properties,并向 checkOut 字段添加一个定制验证消息:hotelStay.checkOut.validator.invalid=Sorry, you cannot check out before you check in

保存 messages.properties 文件并尝试保存有缺陷的 HotelStay。您将看到如清单 11 所示的错误消息:

清单 11. 定制验证错误消息
定制验证错误消息

现在应该编写测试了,如清单 12 所示:

清单 12. 测试定制的验证
import java.text.SimpleDateFormat
class HotelStayTests extends GroovyTestCase {
  void testCheckOutIsNotBeforeCheckIn(){
    def h = new HotelStay(hotel:"Radisson")
    def df = new SimpleDateFormat("MM/dd/yyyy")
    h.checkIn = df.parse("10/15/2008")
    h.checkOut = df.parse("10/10/2008")
  
    assertFalse "there should be errors", h.validate()
    def badField = h.errors.getFieldError('checkOut') 
    assertNotNull "I'm expecting to find an error on the checkOut field", badField
    def code = badField?.codes.find {it == 'hotelStay.checkOut.validator.invalid'} 
    assertNotNull "the checkOut field should be the culprit", code                 
  }
}

测试定制的 TagLib

接下来是最后一个需要处理的用户场景。您已经在 createedit 视图中成功地处理了 checkIncheckOut 的时间戳 部分,但它在 listshow 视图中仍然是错误的,如图 12 所示:

图 12. 默认的 Grails 日期输入(包括时间戳)
默认的 Grails 日期输入(包括时间戳)

最简单的解决办法是定义一个新的 TagLib。您可以利用 Grails 已经定义的 <g:formatDate> 标记,但创建一个自己的定制标记也很容易。我想创建一个可以以两种方式使用的 <g:customDateFormat> 标记。

一种形式的 <g:customDateFormat> 标记打包一个 Date,并接受一个接受任何有效 SimpleDateFormat 模式的定制格式属性:

<g:customDateFormat format="EEEE">${new Date()}</g:customDateFormat>

因为大多数用例都以美国的 “MM/dd/yyyy” 格式返回日期,所以如果没有特别指定,我将采用这种格式:

<g:customDateFormat>${new Date()}</g:customDateFormat>

现在,您已经知道了每个用户场景的需求,那么请输入 grails create-tag-lib Date(如清单 13 所示),以创建一个全新的 DateTagLib.groovy 文件和一个相应的 DateTagLibTests.groovy 文件:

清单 13. 创建一个新的 TagLib
$ grails create-tag-lib Date
[copy] Copying 1 file to /src/trip-planner2/grails-app/taglib
Created TagLib for Date
[copy] Copying 1 file to /src/trip-planner2/test/integration
Created TagLibTests for Date

将清单 14 中的代码添加到 DateTagLib.groovy:

清单 14. 创建定制的 TagLib
import java.text.SimpleDateFormat

class DateTagLib {
  def customDateFormat = {attrs, body ->
    def b = attrs.body ?: body()
    def d = new SimpleDateFormat("yyyy-MM-dd hh:mm:ss").parse(b)
    
    //if no format attribute is supplied, use this
    def pattern = attrs["format"] ?: "MM/dd/yyyy"
    out << new SimpleDateFormat(pattern).format(d)
  }
}

TagLib 接受属性形式的简单的 String 值和标记体,并将一个 String 发送到输出流。由于您将使用这个定制标记封装未格式化的 Date 字段,所以需要两个 SimpleDateFormat 对象。输入对象读入一个与 Date.toString() 调用的默认格式相匹配的 String。当将其解析为适当的 Date 对象之后,您就可以创建第二个 SimpleDateFormat 对象,以便以另一种格式的 String 将它传回。

使用新的 TagLib 在 list.gsp 和 show.gsp 中封装 checkIncheckOut 字段。如清单 15 所示:

清单 15. 使用定制的 TagLib
<g:customDateFormat>${fieldValue(bean:hotelStay, field:'checkIn')}</g:customDateFormat>

输入 grails run-app,然后访问 http://localhost:9090/trip/hotelStay/list,检查实际使用中的定制 TagLib,如图 13 所示:

图 13. 使用定制 TagLib 的数据输出
使用定制 TagLib 的数据输出

现在,编写清单 16 中的几个测试,用来检查 TagLib 是否按照预期工作:

清单 16. 测试定制的 TagLib
import java.text.SimpleDateFormat

class DateTagLibTests extends GroovyTestCase {
    void testNoFormat() {
      def output = 
         new DateTagLib().customDateFormat(format:null, body:"2008-10-01 00:00:00.0")
      println "\ncustomDateFormat using the default format:"
      println output
      
      assertEquals "was the default format used?", "10/01/2008", output
    }

    void testCustomFormat() {
      def output = 
         new DateTagLib().customDateFormat(format:"EEEE", body:"2008-10-01 00:00:00.0")
      assertEquals "was the custom format used?", "Wednesday", output
    }
}

结束语

到目前为止,您已经编写了几个测试,并看到了用它们测试 Grails 组件是多么简单!但是您可以继续开拓,不断取得进步,这会让您对工作更加自信。将自己的测试和用户场景匹配起来有这样的好处:您将拥有一组永远保持最新的可执行文档。

在下一篇文章中,我将重点讨论 JavaScript Object Notation (JSON)。Grails 具有出色的开箱即用的 JSON 支持。您将了解如何通过控制器生成 JSON,以及如何在 GSP 中使用它。在此期间,享受精通 Grails 带来的乐趣吧。

参考资料

学习

  • 您可以参阅本文在 developerWorks 全球网站上的 英文原文
  • 精通 Grails:阅读本系列的其他文章,进一步了解 Grails 及其功能。
  • Grails:访问 Grails Web 站点。
  • Grails Framework Reference Documentation:Grails 权威书籍。
  • Static Typing & Bureaucracy Redux”(Neil Ford,Meme Agora,2007 年 5 月):在这个博客里,Neil Ford 认为动态语言可以在更短的时间内进行更多的测试。
  • Using JUnit 4 with Groovy:您可以将 JUnit 4 和 Grails 一起使用,前提是您目前使用的是 Groovy 1.5+ 和 Java 5+。这里提供一些示例。
  • Test'N'Groove:Test'N'Groove 集成了 Groovy 和 TestNG。
  • Unit Testing:阅读 Groovy 如何为 JUnit 测试提供便利。您可以在这里找到所有支持的断言的完整列表。
  • 追求代码质量: 亲身体验行为驱动开发”(Andrew Glover,developerWorks,2007 年 9 月):更多地关注程序的行为,而不是程序的结果。
  • Groovy Recipes:从 Scott Davis 的最新著作中更多地了解 Groovy 和 Grails。
  • 实战 Groovy:这份 developerWorks 系列文章专门介绍 Groovy 的实际应用,教授什么时候以及如何成功地应用它们。
  • Groovy:在 Groovy 项目的网站上学习关于它的更多内容。
  • AboutGroovy.com:关注 Groovy 的最新新闻和文章链接。
  • 技术书店:浏览关于这个主题和其他技术主题的图书。
  • developerWorks Java 技术专区:找到数百篇关于 Java 编程各个方面的文章。

获得产品和技术

  • Grails:下载 Grails 的最新发行版。
  • easyb:下载 easyb,一个针对 Java 平台的行为驱动开发框架。

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Java technology
ArticleID=349102
ArticleTitle=精通 Grails: 测试 Grails 应用程序
publish-date=10312008