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