精通 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.四、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 带来的乐趣吧。