Dan Allen 谈 Arquillian 测试框架

Arquillian 是一个集成测试、功能测试平台，可用于 Java 中间件的测试。Arquillian 的主要目的是简化集成测试和功能测试的编写，让它们能像单元测试一样简单，Arquillian 能在运行时环境里进行测试，不需要开发人员在测试里处理运行时环境。

Arquillian 能集成 Java EE 容器（像 JBoss AS 和 GlassFish）和 Servlet 容器（比如 Tomcat 和 Jetty），也可以在云服务里运行测试。对容器的支持能让开发人员针对各种技术平台进行测试，包括 Java EE 5 和 6、Servlet 环境、OSGi、嵌入式 EJB 和独立的 CDI。

Arquillian 团队前不久发布了 1.0.0.Final 版本，并打算在不久之后再发布一个版本。

新版本包含的一些功能有：

• 能在单个测试里跨多个容器和多个域控制器进行多次部署
• 新配置方案支持一个容器进行多份配置
• 用 Java 属性覆盖表达式语言（EL），比如属性和配置里的赋值
• 测试方法可以明确定制
• 对容器的生命周期进行细粒度的控制

InfoQ 有幸对 Arquillian 的发言人 Dan Allen 进行了采访，向他了解了测试框架的功能，该框架的方法和其他测试策略有何不同，以及以后版本会有哪些可用的新特性。

InfoQ：Arquillian 是哪种类型的测试？单元测试、集成测试、功能测试、性能测试、安全测试，抑或是其他？

Dan Allen：单元测试的下一步就是 Arquillian，它提供的平台能覆盖现有测试所不能涵盖的范围。只要你开始把组件集成到运行时环境里，无论这个运行时环境是嵌入式的还是独立式的，你都需要一个服务去管理运行时环境。这正是 Arquillian 的核心关注点。Arquillian 把测试带到运行时环境里，然后委托给扩展模块来执行，这些扩展模块能集成组件、调用服务、浏览网页、衡量性能指标、报告代码覆盖率、通过云运行测试，当然这只是举了几个例子。Arquillian 是测试自动化的引擎。

Arquillian 揭示出，部分内容的单元测试在整个测试计划里发挥的作用微乎其微，只使用 JUnit 和 TestNG 是不够的。最终，你必须要为每种测试类型各写一个基类。Arquillian 能把不同的测试服务（比如 Selenium、DBUnit、JaCoCo）集成到一个单一的管道里。

如果你正在使用 CDI 或 Spring 这样的编程模型，你可能也会决定用 Arquillian 来测试嵌入式服务容器里的各个单元。这模糊了单元测试和集成测试之间的界线，但由于你能专注测试的目标，而不是测试该如何划分，所以还是很不错的。

InfoQ：Arquillian 框架有哪些子项目？

Dan：Arquillian 本身没有子项目。相反，它把那些能插入核心平台的模块组织成了网络图的形式。这么安排能很好地集成 Arquillian，无论是从内部还是从外部。事实上，我们更希望项目能为他们自己的 Arquillian 扩展模块提供服务，因为这样集成得更紧密，也能和项目的发布保持同步。

目前有五类模块：

1. 容器适配器
2. 测试增强器
3. 测试运行器
4. 扩展模块
5. 工具

Arquillian 还集成了三个 ShrinkWrap 模块：归档文件、描述符和解析器。

容器适配器是 Arquillian 里最常见的模块类型，因为我们打算支持所有主要的 Java 容器（也就是服务器），最终也会支持一些非 Java 的服务器。项目目前为十二款容器提供了适配器，包括 JBoss AS、GlassFish、Apache Tomcat、Jetty、WebLogic Server、Websphere AS，还有 OpenShift 和 CloudBees 这两个云提供程序。这些适配器都提供了三种管理方式（嵌入式、管理式和远程的），而且覆盖好几个主要发布版本。这就有很多适配器了:)

另一个主要模块是 Arquillian Drone 及其配套组件 Arquillian Graphene。有了这些扩展模块，搭建、管理 Selenium、WebDriver 及其他浏览器驱动器就能省去所有的麻烦。你需要做的只是把浏览器 API 注入到你的测试里，并给它发送命令。通过把应用部署和浏览器控制集成在一起，你完全可以进行端到端的测试。OpenShift 前不久宣布集成了 SauceLabs，这能让你从运行在云里的 Jenkins 上，用 Arquillian 执行跨平台的浏览器测试。

和 Drone 有些类似的扩展模块是 Android 扩展，它在设备上安装了应用程序，然后会控制 Android 的 UI，而不是浏览器。

还有两个模块刚刚开始，我们正密切关注着。一个是 Arquillian Persistence Extension，它为 DBUnit 提供了声明式的控制和附加组件；另一个是 Arquillian Spring Extension，它允许 Spring 开发人员用 Arquillian 替换 Spring 的测试框架，并能访问所有的 Arquillian 扩展模块，特别是 Drone。Google Summer of Code 项目目前就是在开发 Arquillian Spring Extension。

最后要提一下的是用于 JBoss Forge 的 Arquillian 插件，这个模块提供了平台的入口点。简单说来，想要在你的项目里搭建 Arquillian，没有比这更快的方式了，只需要一条命令就可以搞定。

InfoQ：Arquillian 框架有没有受 BDD 和 TDD 这些测试实践的影响？

Dan：设计 Arquillian 的时候，Arquillian 的使用者和被测试内容都受到了 BDD、TDD、ATDD 等测试实践的影响。

我们希望开发人员能尽早测试、经常测试、并能真实测试。作为开发人员，你可以编写一组使用嵌入式或模拟运行时环境的单元测试和集成测试，结果到后面你才会发现违反了运行时相关的基本假设（类加载行为、可见性、文件系统方案），这让你的所有工作付之东流。你必须去测试真实的东西。到目前为止，这么做还是很冒险的，因为这意味着要打包你的项目并全部部署。利用 ShrinkWrap 的微部署，你可以创建非常有针对性的集成测试，并把它们作为沿途的检查点。项目过程中你就再也不用掩面叹息了。

我常说 Arquillian 是个学习环境。在开发过程的早期，你就可以在“真实的”运行时环境里测试你对框架的假设或理解了。你可能会惊讶于这种学习方式是如此之快。

Arquillian 也在努力集成、支持 BDD 和 ATDD 框架，比如 Spock 、 JBehave 和 Thucydides 。这是明年发展的主要领域。

InfoQ：Arquillian 支持在容器里测试应用，这种做法会不会导致开发人员不重视一些设计实践，比如类之间的松耦合、隔离和模块化？

Dan：这个问题问得好。Arquillian 把测试代码放在了容器里，这确实很容易让你忽略前面提到的一些设计实践，不过 ShrinkWrap 会对此有所平衡。每编写一个测试用例，开发人员必须得有意识地去决定什么东西要放在测试归档文件里，测试归档文件会成为测试的缩影（因而也是 classpath 可见性的范围）。虽然有些开发人员起初会觉得这很乏味，但很快他们就会认识到，这提供了一种独特的隔离级别，可以仔细研究类和库之间的依赖关系。

开发人员期望在嵌入式服务容器（例如 Weld Embedded）里运行测试，这能敦促他们尽量避免在边界层之外和容器资源有过多的耦合。虽然他们在开发过程中可能会使用嵌入式容器，但在进行持续集成时，他们会对运行在“真实”容器里的测试觉得心安。

总之，Arquillian 和 ShrinkWrap 能互相牵制，平衡好有意义的反馈和良好的设计。

InfoQ：Arquillian 测试框架有什么局限？

Dan：Classpath 管理和不够 Java 模块化。开发人员为运行在容器里的代码编写测试的时候，经常会遇到这些问题。Java 工具（构建工具、IDE）和运行时环境（应用服务器）往往不太关心 classpath，或者没有其他选择。结果在运行时环境里，开发人员就开始遇到非常奇怪的问题，却把这些问题归因于 Arquillian 或 ShrinkWrap。真正可以抱怨的是 Arquillian 还没有进行 Java 模块化。使用嵌入式容器时，这个问题特别常见。我最近在 Arquillian 的博客上讨论了这个问题。幸运的是，解决办法很简单，使用运行在独立虚拟机里的受管容器就可以了。

另一个局限是可用性方面的一些问题。开发人员在不同的容器适配器之间切换时还有一点儿麻烦，一部分原因是切换需要使用 classpath 配置，另一部分原因是容器配置的选择还不够智能。目前开发人员使用 Arquillian，必须要去学习的内容只有这些。如果开发人员阅读了 Arquillian 的手册，他们就能顺利开始并进行。

我们在手册里倾注了很多心血，以便帮助开发人员上手。目前所作的这些非常有用。但我们的文档仍然不是很全，所以我们还需要继续关注文档这部分内容，好帮助开发人员顺利进行。

InfoQ：关于新功能和增强，以后有什么详细计划么？

Dan：什么都可能是新功能和增强。Arquillian 的文化是鼓励创新和丰富的想象。这里先让大家了解一下我们对未来的设想，请查看团队向 Google Summer of Code 2012 计划提出的十二条建议。那个列表很好地描绘了我们的预想。这里我列出几个关键条目：

• Spring Beans 和 MVC 的测试
• 在运行的测试里进行浏览器截图的自动化视觉对比
• 自动化的 JavaScript 测试
• 更多有效的持久化测试
• 用 JRebel 进行 Java 类和资源的自动重部署
• 增强 ShrinkWrap 描述符和解析器，从而简化对部署组装的控制
• 支持非 Java 服务器，比如 Apache HTTPD
• 可用性

感兴趣的读者可以检出专门设计的指南，从一个空的工作区开始，按照上面的内容用 Arquillian 得到第一个全部通过的 Green Bar。

关于受访者

Dan Allen是个开源倡导者、社区参与者、作家，还是个讲师。他目前是 Red Hat 的首席软件工程师，并扮演着前面说的几种角色。他是 JBoss 社区的联络人员，同时参与好几个 JBoss 社区项目，包括 Arquillian、ShrinkWrap、Seam 3/DeltaSpike 和 JBoss Forge，他还作为 Red Hat 的代表参与 JCP 的事务。Dan 是《Seam in Action》一书（2008 年由 Manning 出版）的作者，并为 IBM developerWorks、NFJS 杂志和 JAXenter 撰稿。他还是国际公认的讲师，出席过数届 JavaOne、Devoxx、NFJS、JAX 和 Jazoon 软件大会。每天的会议议程结束后，你可能还会看见 Dan 拿着比利时 Trappist 啤酒在和志同道合的社区成员讨论技术。

查看英文原文： Dan Allen on Arquillian Testing Framework

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。