Dan Allen谈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扩展模块提供服务，因为这样集成得更紧密，也能和项目的发布保持同步。

　　目前有五类模块：

　　容器适配器

　　测试增强器

　　测试运行器

　　扩展模块

　　工具

　　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可见性的范围)。虽然有些开发人员起初会觉得这很乏味，但很快他们就会认识到，这提供了一种独特的隔离级别，可以仔细研究类和库之间的依赖关系。

原文转自：http://www.ltesting.net