相关内容

返回首页

Arquillian 1.0.0 Alpha 1 版本发布！

发布者：    |       Arquillian Seam

我很高兴宣布 Arquillian 的第一个 alpha 版本发布，Arquillian 是一个开源（ASL v2）框架，用于在容器中运行测试。如果您想了解更多关于 Arquillian 的使命以及它如何融入我们在 JBoss 的测试愿景中，请阅读 Pete 的博客。

在容器外部对代码进行单元测试是一回事，但当你将其运行在内部时会发生什么？它是否仍然表现相同？针对容器管理资源进行测试又是怎样的情况？这就是 Arquillian 发挥作用的地方。

使用 Arquillian，编写集成测试与单元测试一样简单。事实上，为了最小化对 您 的负担，Arquillian 集成到熟悉的测试框架中，允许重用您在喜欢的 IDE 中使用的 JUnit/TestNG 支持、Maven Surefire、Ant 等，实际上任何支持 TestNG 或 JUnit 的工具！

为了展示这有多么简单，以下是一个使用 JUnit 的测试用例设置示例：（我们将在下一个示例中进行实际的测试）

@RunWith(org.jboss.arquillian.junit.Arquillian.class)
public class TemperatureConverterTestCase {

   @Deployment
   public static JavaArchive createTestArchive() {
      return Archives.create("test.jar", JavaArchive.class)
         .addClasses(TemperatureConverter.class, TemperatureConverterBean.class);
   }

}

通过使用 JUnit 的@RunWith注解，您告诉 JUnit 使用 Arquillian 作为测试控制器。Arquillian 然后查找带有@Deployment注解的静态方法，该方法创建您的微部署。在上面的示例中，我们只是部署了一个会话 Bean 接口和实现。

Arquillian 集成到您的测试框架生命周期中，并响应事件。在套件开始和结束事件上，容器启动/停止，而在类开始和结束事件上，您的微部署被部署到/从容器中卸载。

测试用例在本地 JVM 中启动，然后 Arquillian 覆盖正常的测试执行，并将测试迁移到容器中执行。当测试框架调用您的@Test注解方法，测试在容器内运行，使我们能够与容器管理资源一起工作。以下是完整的JUnit测试类@Test方法。

@RunWith(org.jboss.arquillian.junit.Arquillian.class)
public class TemperatureConverterTestCase {

   @Deployment
   public static JavaArchive createTestArchive() {
      return Archives.create("test.jar", JavaArchive.class)
         .addClasses(TemperatureConverter.class, TemperatureConverterBean.class);
   }

   @EJB
   private TemperatureConverter converter;

   @Test
   public void shouldConvertToCelsius() {
      Assert.assertEquals(converter.convertToCelsius(32d), 0d);
      Assert.assertEquals(converter.convertToCelsius(212d), 100d);
   }

   @Test
   public void shouldConvertToFarenheit() {
      Assert.assertEquals(converter.convertToFarenheit(0d), 32d);
      Assert.assertEquals(converter.convertToFarenheit(100d), 212d);
   }
}

注意我们如何使用@EJB来将我们的部署中的会话Bean注入到测试用例中，以在我们的测试方法中使用 - 真棒！

Arquillian TestEnricher SPI支持Java EE 6的所有注入注解 -@EJB, @Resource和@Inject.

此示例测试用例可以在GlassFish、JBoss AS或OpenEJB上运行，因为没有任何容器特定的代码/配置。选择权在你手中。你甚至可以在多个平台上进行测试！

我想了解更多，我应该从哪里开始？

你可以阅读这些文章中描述的深入使用场景和测试

我们还有参考文档，它将引导您通过Arquillian的示例，并显示如何创建自己的Arquillian测试套件。您可能还会发现Javadoc和有用的，特别是如果您计划添加对另一个容器的支持。您还可以查看论坛，更多文章可以在我们的社区网站上找到。如果您有兴趣与我们交谈，请访问#jbosstesting在irc.freenode.net

那么，接下来是什么？

您可以从Arquillian期待以下内容

  • 本地运行模式 -- 有时候，您不想在容器内部运行测试用例。将添加本地运行模式；一种您的测试控制部署但不作为其一部分部署的模式。这将给您机会运行一个针对示例的测试，例如，JSF页面或RMI（测试那些讨厌的非序列化/会话已关闭异常）。
  • 同一测试控制多个部署 -- 有时候您的微部署不足以单独测试，您想要将其他组件作为同一部署的一部分打包。例如，您需要测试两个Web应用之间的交互。
  • 支持方法参数注入 -- 在第一个alpha版本中，我们只支持字段注入。在alpha 2中，我们将扩展TestEnricher SPI以包括对方法参数注入的支持
@Test
public void shouldWithdrawFromAccount(@EJB AccountManager manager) throws Exception
{
   ...
}
  • 测试方法拦截器 -- 另一个计划中的enricher SPI是测试方法拦截器。通过这个，我们可以添加对事务的支持
@Test
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public void shouldWithdrawFromAccount(@EJB AccountManager manager) throws Exception
{
   ...
}
  • 约定优于配置 -- 微部署应该尽可能简单易用，因此添加对常见约定的支持将有助于加快测试开发速度。例如，我们可以自动将测试类同一包中的所有类添加到部署中
  • Arquillian控制资源 -- 有时候，容器需要特定的容器配置，例如java.naming.*创建InitialContext所需参数。如果测试用例必须明确处理此参数，那么将容器可移植性的负担再次转嫁给测试用例的作者。Arquillian将提供一个扩展点来添加Arquillian创建/管理的资源
// auto creation of InitialContext based on running container, remote or local.
@ArquillianResource
private InitialContext context;

// auto creation of URL to a specific deployed Servlet, including http port/ip etc.
@ArquillianResource(MyServlet.class)
private URL myServletURL;

// the bundle context of a deployed osgi bundle
@ArquillianResource
private BundleContext context;
  • 添加更多容器的支持 -- 我们计划支持更多容器！目前我们已计划支持：GlassFish 3（作为远程容器）、Jetty、Tomcat、Resin、Felix OSGI。（嘿，Spring的朋友们，也欢迎你们加入！）
  • 第三方集成 -- 在便于开发的精神指导下，我们尽可能与现有测试框架集成，但我们始终乐于了解我们可以集成的新的框架。例如，我们已经计划支持Selenium。
  • 对其他构建工具的支持 -- Arquillian Alpha1版本包含Maven支持。在未来的版本中，我们将提供针对其他构建工具（如Ant和Gradle）的构建（那是对我们驻地的Gradle专家Jason Porter的致敬）。
  • 项目页面、标志和艺术作品 -- 所有美好的事物都应该看起来很美。这就是为什么JBoss.org的设计团队正在努力为Arquillian项目页面准备艺术作品。敬请期待！

在哪里可以看到Arquillian的应用？

Arquillian是一个新的框架，但它的首要任务将是作为所有Seam 3模块的测试工作马。它也将成为我们推荐用于测试Seam应用的解决方案。（我们非常希望社区尝试用它来测试Seam 2应用）。我们还将用Arquillian替换JSR-299 CDI TCK的当前核心，很可能是TCK的1.1版本。（为了提供一点历史背景，Arquillian起源于由Pete Muir开发的JBoss Test Harness，它是CDI TCK的基础）。

如果您对这些想法有任何想法，或者想要建议我们应该探索的新途径，请通过Arquillian Dev论坛联系我们。

没有社区的开源项目还有什么意义呢？！

衷心感谢Arquillian和ShrinkWrap社区为此版本提供帮助，他们是早期采用者，参加了社区会议，进行了一般讨论，并撰写了博客、文章和补丁。按字母顺序排列：Dan Allen、Steven Boscarine、German Escobar、Jordan Ganoff、Ken Gullaksen、Pete Muir、Jason Porter、Andrew Lee Rubinger。你们太棒了！

[ JIRA ] | [ SPI Javadoc，API Javadoc ] | [ 参考指南 ] | [ 发行说明 ] | [ Maven组件 ]

返回顶部