Juven Xu

作为一个已经写了近5年Java代码的程序员，我直到最近才算是基本明白了异常应该怎么用，这真是令人汗颜。事情是这样的，上周，和往常一样，我在开发一个很平常的应用，并且不得不面对各种各样的异常，比如常见的IOException，或者用到个第三方类库可能会给你返回ThirdPartyException，还有，我自己也会定义异常，姑且叫它MyOwnException。我是使用分层的架构写代码的，比如有个REST层，有个领域模型层，有持久化层，这本没什么问题，可当我发现一个接口要throws三四个或者更多的异常的时候，就觉得蛋疼了，这不仅看起来恶心，如调用者如何处理它们似乎也是个问题。这不是第一次，其实之前蛋疼过很多次了，我一直阅读各种OO设计相关书籍，以理解如何组织各种类和对象，可我还真没仔细考虑过如何组织异常。

好吧，为了以后不再蛋疼，我得弄清楚这个异常的用法。我希望能够明白如何组织异常才能使其变得整洁，而不是肆无忌惮地污染我精心设计的接口。

我翻阅了相关书籍，仔细查看了它们关于异常的描述，包括

• Implementation Patterns — Kent Beck
• Clean Code: A Handbook of Agile Software Craftsmanship — Robert C. Martin
• Effective Java (2ed) — Joshua Bloch
• Robust Java: Exception Handling, Testing, and Debugging — Stephen Stelting

边阅读边思考，最终基本理解了异常处理的最佳实践。值得一提的是，这几本书中 Joshua Bloch 的描述相比最为全面和深刻，Kent Beck 的最简单粗糙，Robert C. Martin 一书的那一章其实是 Michael Feathers 写的，也只能算是一般，Stephen Stelting 的描述看起来很全面，可太理论了，实例太少，没有说服力。

那异常处理的最佳实践到底是什么？首先要理解的是，异常到底是什么，我觉得异常分两类。

第一是业务异常，就是处理业务的时候80%的时候是没问题的，但可能有20%的时候事情没有按理想的方向发展。例如注册用户的时候，正常情况是注册成功，但可能用户提交请求的时候，系统发现用户名已经被别人注册了，这是就可以抛出一个UserAlreadyExistsException。

第二是系统异常，系统异常与具体业务流程没有直接的关系，例如编程错误导致的NullPointExcpetion，还有坏境问题，例如磁盘损坏或者网络连接不稳定造成了IOException。

先谈谈业务异常，业务异常应该是接口的一部分，该接口的用户应该能够处理该异常。也就是说，在实现接口之前，就应该定义清楚这个接口会抛出怎样的异常，例如注册用户这个接口就应该明确定义会抛出UserAlreadyExistsException，并辅以必要文档，那调用者就知道怎么去处理。如果你在接口声明异常，那你一定要确保接口的调用者能够处理之。例如对应于 UserAlreadyExistsException，用户界面可以提示用户该ID已存在，那用户可以使用另外的ID来注册。注意，处理异常不是简单的catch，然后随便打印点日志那么简单，业务异常的处理应当遵照业务流程。

而系统异常由于没有实际业务意义，调用者往往是不知道如何处理的。例如注册用户的时候收到一个IOException，你只会一头雾水。那系统异常应该如何处理呢？有这么几个选择：

1. 能在底层处理的就本地处理掉，例如网络连接超时异常，可以编写代码尝试再次连接。
2. 能翻译为业务异常的就翻译，有时候你可能发现某个IOException对应有实际的业务意义，但不要直接抛出，而是应该Exception Chaining技术来翻译，例如 throw new MyOwnException(“sorry, …”, ioe)，这样既不至于丢失原始信息，业务接口也更容易理解。
3. 实在无法处理的，就转换为RuntimeException，反正调用者也不知道怎么处理，那在接口中声明是没有意义的，只会造成调用者困惑并带来负担。这里同样应该使用Exception Chaining以避免信息丢失。我的实际经验告诉我，很多人完全都不考虑使用RuntimeException，这真是莫大的浪费。

有时候业务异常和系统异常的角色会相互转换，例如 FileNotFoundException 对于文件处理这个领域来说是业务异常，可对于我的应用来说，可能只是一个系统异常。

上述是我认为异常处理最核心最有用的实践，除此之外还有不少前人总结的经验，包括：

• 记录异常，但只记录一次。（不要丢失历史）
• 不要返回及传Null值。（避免NullPointException和不必要的检查）
• 尽量重用JDK自带的异常。（以降低学习成本）
• 在自定义异常中存储异常相关信息字段。（以方便日后处理）
• 永远不要直接忽略异常。（不要丢失历史）
• 为异常声明写Javadoc。（对你的用户有好些）
• 不要 throws 或者 catch 顶层的 Exception 类。（天知道Exception对应什么业务信息）

其实当我读毕前面提到的几本书，然后再Google相关文档的时候，就发现已经有人基本总结过这些内容了：Best Practices for Exception Handling, by Gunjan Doshi， 文章是2003年写的，但一点也不过时。相比之下我这篇文章有污染搜索引擎之嫌，不管怎样，这算是自我的一个总结，对英文不好的人应该也有些价值。

自动化集成测试的角色

本专栏的上一篇文章讲述了Maven与持续集成的一些关系及具体实践，我们都知道，自动化测试是持续集成必不可少的一部分，基本上，没有自动化测试 的持续集成，都很难称之为真正的持续集成。我们希望持续集成能够尽早的暴露问题，但这远非配置一个 Hudson/Jenkins服务器那么简单，只有真正用心编写了较为完整的测试用例，并一直维护它们，持续集成才能孜孜不倦地运行测试并第一时间报告问 题。

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

基于Maven的一般流程

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

1. 启动Web容器
2. 部署待测试Web应用
3. 以Web客户端的角色运行测试用例
4. 停止Web容器

启动Web容器可以有很多方式，例如你可以通过Web容器提供的API采用编程的方式来启动容器，但在Maven的环境下，配置插件显得更简单。如果你了解Maven的生命周期模型， 就可能会想到，我们可以在pre-integration-test阶段启动容器，部署待测试应用，然后在integration-test阶段运行集成 测试用例，最后在post-integrate-test阶段停止容器。也就是说，对于步骤1，2和4我们只须进行一些简单的配置，不必编写额外的代码。 第3步是以黑盒的形式模拟客户端进行测试，需要注意的是，这里通常要求你理解一些基本的HTTP协议知识，例如服务端在什么情况下应该返回HTTP代码 200，什么时候应该返回401错误，以及所支持的Content-Type是什么等等。

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

一个简单的例子

谈了不少理论，现在该给个具体的例子了，譬如现在有个简单的Servlet，它接受参数a和b，做加法后返回二者之和，如果参数不完整，则返回HTTP 400错误，表示客户端的请求有问题。

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需要用到的TCP端口及消息关键字。接着是两个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。第二个测试方法则用来测试失败的场景，当不提供参数的时 候，服务器应该返回一个HTTP 400错误。该测试类其实是相当粗糙的，例如有硬编码的服务器URL，这里的目的仅仅是通过尽可能简单的代码来展现一个自动化集成测试的实现过程。

上述代码中，测试类的名称为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感兴趣。

本文已经首发于InfoQ中文站，版权所有，原文为《Maven实战（五）——自动化Web应用集成测试》，如需转载，请务必附带本声明，谢谢。
InfoQ中文站是一个面向中高端技术人员的在线独立社区，为Java、.NET、Ruby、SOA、敏捷、架构等领域提供及时而有深度的资讯、高端技术大会如QCon 、线下技术交流活动QClub、免费迷你书下载如《架构师》等。