Dan Allen谈Arquillian测试框架(2)

　　开发人员期望在嵌入式服务容器(例如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。

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