精通 Grails: 测试 Grails 应用程序

排除 bug，构建可执行文档
Grails 可以轻松确保您的应用程序从始至终都远离 bug。这还有另一个好处，您可以利用测试代码生成一组通常是最新的可执行文档。本月 Grails 专家 Scott Davis 向您展示如何对 Grails 进行测试。
查看本系列更多内容 |   评论：
Scott Davis , 主编, AboutGroovy.com
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 有各种不同的断言方法，包括 assertEquals、assertTrue 和 assertNull 等等。它使您通过编程的方式表明 “我断言这个代码按照预期工作”。
为什么是 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 件重要的事情：
可以看到，environment 被设置为 test。这意味着 conf/DataSource.groovy 文件中的 test 块的数据库设置已生效。
test/unit 中的脚本已运行。您尚未编写任何单元测试，所以不能找到任何单元测试，这并不奇怪。
test/integration 中的脚本已经运行。您可以看到 HotelStayTests.groovy 脚本的输出 — 它的旁边有个很大的 SUCCESS。
这个脚本向您展示一组报告。
如果您在 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 checkIn 和 Date 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 支持的所有断言，包括 assertArrayEquals、assertContains 和 assertLength）。
回页首
添加控制器和视图
到目前为止，您一直以编程的方式与 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 字段 — 如果您不希望留下中断的测试的话。
如果仍然显示关于 checkIn 和 checkOut 的验证错误，您不必担心。就这个测试而言，您完全可以忽略它们。但是这表明您不应该仅测试错误是否出现 — 您应该确保特定的 错误被抛出。
注意，我没有断言定制错误消息的确切文本。为什么我上一次关注匹配的字符串（测试 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
接下来是最后一个需要处理的用户场景。您已经在 create 和 edit 视图中成功地处理了 checkIn 和 checkOut 的时间戳 部分，但它在 list 和 show 视图中仍然是错误的，如图 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 中封装 checkIn 和 checkOut 字段。如清单 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 带来的乐趣吧。