Maven实战（五）——自己主动化Web应用集成測试

自己主动化集成測试的角色

本专栏的上一篇文章讲述了Maven与持续集成的一些关系及详细实践，我们都知道，自己主动化測试是持续集成不可缺少的一部分，基本上，没有自己主动化測试的持续集成，都非常难称之为真正的持续集成。我们希望持续集成可以尽早的暴露问题。但这远非配置一个 Hudson/Jenkinsserver那么简单，仅仅有真正用心编写了较为完整的測试用例。并一直维护它们，持续集成才干孜孜不倦地执行測试并第一时间报告问题。

自己主动化測试这个话题非常大，本文不想争论測试先行还是后行，这里强调的是測试的自己主动化，并基于详细的技术（Maven、 JUnit、Jetty等）来介绍一种切实可行的自己主动化Web应用集成測试方案。当然。自己主动化測试还包含单元測试、验收測试、性能測试等，在不同的场景下，它们都能为软件开发带来极大的价值。本文仅限于讨论集成測试，主要是由于笔者认为这是一个非常重要却经常被忽略的实践。

基于Maven的一般流程

集成測试与单元測试最大的差别是它须要尽可能的測试整个功能及相关环境，对于測试Web应用而言，通常有这么几步：

1. 启动Web容器

2. 部署待測试Web应用

3. 以Webclient的角色执行測试用例

4. 停止Web容器

启动Web容器能够有非常多方式。比如你能够通过Web容器提供的API採用编程的方式来启动容器，但在Maven的环境下，配置插件显得更简单。

假设你了解Maven的生命周期模型。就可能会想到，我们能够在pre-integration-test阶段启动容器，部署待測试应用。然后在integration-test阶段执行集成測试用例，最后在post-integrate-test阶段停止容器。

也就是说，对于步骤1，2和4我们仅仅须进行一些简单的配置，不必编写额外的代码。

第3步是以黑盒的形式模拟client进行測试，须要注意的是，这里通常要求你理解一些主要的HTTP协议知识，比如服务端在什么情况下应该返回HTTP代码
200，什么时候应该返回401错误，以及所支持的Content-Type是什么等等。

至于測试用例该怎么写，除了须要用到一些用来訪问Web以及解析响应具体的基础设施工具类之外。其它内容与单元測试大同小异。基本就是准备測试数据、訪问服务、验证返回值等等。

一个简单的样例

谈了不少理论，如今该给个详细的样例了，譬如如今有个简单的Servlet。它接受參数a和b。做加法后返回二者之和，假设參数不完整，则返回HTTP 400错误，表示client的请求有问题。

public class AddServlet
    extends HttpServlet
{
    @Override
    protected void doGet( HttpServletRequest req, HttpServletResponse resp )
        throws ServletException,
            IOException
    {
        String a = req.getParameter( "a" );
        String b = req.getParameter( "b" );

        if ( a == null || b == null )
        {
            resp.setStatus( 400 );
            return;
        }

        int result = Integer.parseInt( a ) + Integer.parseInt( b );

        resp.setStatus( 200 );
        resp.getWriter().print( result );
    }
}

为了測试这段代码，我们须要一个Web容器，这里暂且使用Jetty，由于眼下来说它与Maven集成的相对最好。Jetty提供了一个Jetty
Maven Plugin，借助该插件，我们能够随时启动Jetty并部署Maven默认文件夹布局的Web项目。实现高速开发和測试。

这里我们须要的是在pre-integration-test阶段启动Jetty，在post-integrate-test阶段停止容器，相应的POM配置例如以下：

      <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>jetty-maven-plugin</artifactId>
        <version>7.3.0.v20110203</version>
        <configuration>
          <stopPort>9966</stopPort>
          <stopKey>stop-jetty-for-it</stopKey>
        </configuration>
        <executions>
          <execution>
            <id>start-jetty</id>
            <phase>pre-integration-test</phase>
            <goals>
              <goal>run</goal>
            </goals>
            <configuration>
              <daemon>true</daemon>
            </configuration>
          </execution>
          <execution>
            <id>stop-jetty</id>
            <phase>post-integration-test</phase>
            <goals>
              <goal>stop</goal>
            </goals>
          </execution>
        </executions>
      </plugin>

XML代码中第一处configuration是插件的全局配置，stopPort和 stopKey是该插件用来停止Jetty须要用到的TCPport及消息keyword。接着是两个executation元素，第一个executation将 jetty-maven-plugin的run目标绑定至Maven的pre-integration-test生命周期阶段，表示启动容器，第二个 executation将stop目标绑定至post-integration-test生命周期阶段。表示停止容器。

须要注意的是，启动Jetty时我们须要配置deamon为true。让Jetty在后台执行以免堵塞mvn命令。此外。jetty-maven-plugin的run目标也会自己主动部署当前Web项目。

准备好Web容器环境之后，我们接着看一下測试用例代码：

public class AddServletIT
{
    @Test
    public void addWithParametersAndSucceed()
        throws Exception
    {
        HttpClient httpclient = new DefaultHttpClient();
        HttpGet httpGet = new HttpGet( "http://localhost:8080/add?

a=1&b=2" );
        HttpResponse response = httpclient.execute( httpGet );

        Assert.assertEquals( 200, response.getStatusLine().getStatusCode() );
        Assert.assertEquals( "3", EntityUtils.toString( response.getEntity() ) );
    }

    @Test
    public void addWithoutParameterAndFail()
        throws Exception
    {
        HttpClient httpclient = new DefaultHttpClient();
        HttpGet httpGet = new HttpGet( "http://localhost:8080/add" );
        HttpResponse response = httpclient.execute( httpGet );

        Assert.assertEquals( 400, response.getStatusLine().getStatusCode() );
    }
}

为了可以訪问应用，这里用到了HttpClient。两个測试方法都初始化一个HttpClient，然后创建HttpGet对象用来訪问Web地址。第一个測试方法顾名思义用来測试成功的场景，它提供參数
a=1和b=2，运行请求后，验证返回结果成功（HTTP状态码200）而且内容为正确的值3。第二个測试方法则用来測试失败的场景。当不提供參数的时候。server应该返回一个HTTP 400错误。该測试类事实上是相当粗糙的，比如有硬编码的serverURL，这里的目的不过通过尽可能简单的代码来展现一个自己主动化集成測试的实现过程。

上述代码中，測试类的名称为AddServletIT，而不是一般的**Test。IT表示IntegrationTest，这么命名是为了和单元測试区分开来，这样，鉴于Maven默认的測试命名约定，Maven在test生命周期阶段运行单元測试时，就不会涉及集成測试。如今。我们希望Maven在integration-test阶段运行全部以IT结尾命名的測试类，配置Maven
Surefire Plugin例如以下：

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>2.7.2</version>
        <executions>
          <execution>
            <id>run-integration-test</id>
            <phase>integration-test</phase>
            <goals>
              <goal>test</goal>
            </goals>
            <configuration>
              <includes>
                <include>**/*IT.java</include>
              </includes>
            </configuration>
          </execution>
        </executions>
      </plugin>

通过命名规则和插件配置，我们优雅地分离了单元測试和集成測试。并且我们知道在integration-test阶段。Jetty容器已经启动完毕了。假设你在使用TestNG，那你还能够使用其測试组的特性来分离单元測试和集成測试。Maven Surefire Plugin对其也有着非常好的支持。

一切就绪了。执行 mvn clean install 以自己主动执行集成測试，我们能够看到例如以下的输出片段：

[INFO] --- jetty-maven-plugin:7.3.0.v20110203:run (start-jetty) @ webapp-demo ---
[INFO] Configuring Jetty for project: webapp-demo
[INFO] webAppSourceDirectory /home/juven/git_juven/webapp-demo/src/main/webapp does not exist. Defaulting to /home/juven/git_juven/webapp-demo/src/main/webapp
[INFO] Reload Mechanic: automatic
[INFO] Classes = /home/juven/git_juven/webapp-demo/target/classes
[INFO] Context path = /
...
2011-03-06 14:55:15.676:INFO::Started SelectChannelConnector@0.0.0.0:8080
[INFO] Started Jetty Server
[INFO]
[INFO] --- maven-surefire-plugin:2.7.2:test (run-integration-test) @ webapp-demo ---
[INFO] Surefire report directory: /home/juven/git_juven/webapp-demo/target/surefire-reports

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running com.juvenxu.webapp.demo.AddServletIT
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.344 sec

Results :

Tests run: 2, Failures: 0, Errors: 0, Skipped: 0

[INFO]
[INFO] --- jetty-maven-plugin:7.3.0.v20110203:stop (stop-jetty) @ webapp-demo ---

能够看到jetty-maven-plugin:7.3.0.v20110203:run相应了start-jetty。maven-surefire- plugin:2.7.2:test相应了run-integration-test，jetty-maven- plugin:7.3.0.v20110203:stop相应了stop-jetty，与我们的配置和期望全然一致。此外两个測试也都成功了！

小结

相对于单元測试来说。集成測试更难编写，由于须要准备很多其它的环境，本文只涉及了Web容器最简单的情形。实际的开发情形中，你可能会遇到数据库，第三方Web服务。更复杂的容器配置和数据格式等等。这都使得编写集成測试变得让人畏惧。

然而反过来考虑。不管怎样你都须要測试，尽管这个自己主动化过程的投入非常大。但收益往往更加客观。这不不过手动測试时间的节省，更重要的是，你无法保证手动測试能被高频率的重复运行，也就无法保证问题能被尽早暴露。

对于Web应用来说，编写集成測试有助于你考虑和设计Web应用对外暴露的接口，这样的“开发实现”/“測试审察”之间的角色转换往往能造就更清晰的设计。这也是编写測试最大的优点之中的一个。

Maven用户可以得益于Maven的插件系统，不仅能节省大量的编码，还能得到稳定的工具，Jetty Maven Plugin和Maven Surefire Plugin就是最好的样例。

本文仅仅涉及了Jetty，假设读者的环境是Tomcat或者JBoss等其它容器，则须要查阅相关的文档以得到详细的实现细节。你可能对Tomcat
Maven Plugin、JBoss Maven Plugin、或者Cargo
Maven2 Plugin感兴趣。

原文地址：http://www.infoq.com/cn/news/2011/03/xxb-maven-5-integration-test