开发工具： Maven 02、Maven常用插件

1.基于surefire插件的单测和输出覆盖率报告

1.1 单测

1.1.1 surefire插件介绍

maven 中默认内置了 surefire 插件来运行单元测试，与最新流行的 junit 单元测试框架整合非常好。一般是在default 生命周期的 test 阶段，会运行 surefire 插件的 test goal，然后执行 src/test/java 下面的所有单元测试的。

而 surefire 插件会根据一定的规则在 sre/test/java 下面找单元测试类，具体规则如下：

**/Test*.java
**/*Test.java
**/*TestCase.java

通常比较流行的是用 *Test.java 格式类命名单元测试的类。

1.1.2 跳过单测

如果某次你的确不想要执行单元测试就打包，那么可以跳过单元测试，但是在实际开发过程中，这是绝对不被允许的！

mvn package -DskipTests

1.1.3 指定想要运行的测试类

mvn test -Dtest=**Test

通常见于开发人员自己刚写了某个单元测试类，然后就想自己运行一下看看效果。可以用逗号隔开，也可以用*匹配多个类。

1.1.4 自定义包含与排除测试类

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <version>2.5</version>
  <configuration>
    <includes>
      <include>**/*Tests.java</include>
    </includes>
    <excludes>
      <exclude>**/*TempTest.java</exclude>
    </excludes>
  </configuration>
</plugin>

1.2 测试报告

1.2.1 什么是单元测试覆盖率

比如说，你总共写了 100 行代码

然后你写了 3 个单元测试方法，结果这 3 个单元测试的方法会执行你的 100 行代码中的 80 行，另外有 20 行代码是无论运行哪个单元测试都不会执行的

此时单元测试覆盖率就是 80/100，即80%

1.2.2 常见的覆盖率

比如你一共写了 10 个方法，100 行代码。

1）方法覆盖率

方法覆盖率至少要达到 90%，那么要求就是至少对 10 个方法中的9个方法都要运行

2）行覆盖率

代码覆盖率至少要求 70%，那么要求就是至少对 70 行代码都要执行到

3）分支覆盖率

如果你的代码中有 if else，或者是 try catch，相当于是你的一段代码根据不同的情况，可能会有 2 个分支，分支里面还可以再嵌套 if else，再分出来 2 个分支。

分支覆盖率是指你的单元测试可以覆盖几个分支，1/4，即 25%；2/4，即 50% 分支覆盖率

1.2.3 测试覆盖率报告

在使用 surefire 进行单测时，可以同时引入 cobertura 插件，即看到测试覆盖率的报告

<plugin>  
    <groupId>org.codehaus.mojo</groupId>  
    <artifactId>cobertura-maven-plugin</artifactId>  
    <version>2.5.1</version>  
</plugin>

为什么不配置 executions 去指定这个插件的 goal 绑定到哪儿？
其实每个插件只要定义它的坐标，默认情况下，它自己内部就带了要把哪些 goal 绑定到哪个 phase 上去

为什么不配置 configuration 特殊的参数？
默认如果没有特殊的要求，用默认的参数就够了

2.基于 jetty 插件的冒烟测试

一般来说，在公司里面开发，都是一个常规的路径。写代码，写单元测试，运行单元测试，看一看单测覆盖率，覆盖率不达标，得继续写单元测试，覆盖大部分的代码。

但是对于这个 web 工程来说，除了在本地单元测试以外，你还需要在本地启动 web 服务，然后调用一下 web接口，简单的测试一下，做一个简单的冒烟测试，看看基本的功能是否正常。

2.1 冒烟测试

冒烟测试，传于微软。就是要求开发工程师不能完全依赖于测试工程师去帮你检测代码的质量，至少说你在把代码交付给测试工程师去检测之前，你需要用抽一根烟的时间，简单对你的代码核心和基础的功能跑一下，看看是否基本可以跑通。一般来说，测试工程师，吐槽最多的就是，开发工程师自己看都没看，写完代码就直接给我提测了。

2.2 引入 jetty 插件

<plugin>
	<groupId>org.mortbay.jetty</groupId>
	<artifactId>jetty-maven-plugin</artifactId>
	<version>7.1.6.v20100715</version>
	<configuration>
		<scanIntervalSeconds>10</scanIntervalSeconds>
		<webAppConfig>
			<contextPath>/test</contextPath>
		</webAppConfig>
	</configuration>
</plugin>

• scanIntervalSeconds：指的是自动扫描项目代码变更的时间

• contextPath：指部署之后的 contextPath

jetty 插件的 groupId 不是默认的 org.apache.maven.plugins，因此如果要执行该插件，需要在 settings.xml 中进行配置。

<pluginGroups>
	<pluginGroup>org.mortbay.jetty</pluginGroup>
</pluginGroups>

2.3 执行 jetty

mvn jetty:run，执行 jetty 插件的 run goal，会用 jetty 容器启动 web 应用，默认绑定 8080 端口。

用 mvn jetty:run -Djetty.port=8081 可以修改端口号

2.4 pluginGroups

一般配置了插件以后，如果直接在命令行运行 jetty:run，cobertura:cobertura 等命令，其实用的是插件的缩写，jetty 插件，cobertura 插件。但是如果要将插件的缩写和插件自己的 groupId 对应起来的话，有的时候还是需要去手动做一下配置的，不然在某些环境下可能直接运行类似 jetty:run 的命令可能会有问题。

但是有些插件，比如说 dependency:tree，它的 groupId，是 org.maven.plugins，这个是默认的 maven 内核中的插件，所以不需要额外配置。

3.基于 cargo 对 web 服务进行自动化部署

3.1 cargo 插件介绍

在搞定了整个系统的单测试，web 测试之后，就需要将整个系统完成构建，打出一个完整的 war 包，然后部署到远程服务器的 web 容器里去了，此时就要用 cargo 插件来进行自动化的 web 部署。

3.2 引入插件

<plugin>
	<groupId>org.codehaus.cargo</groupId>
	<artifactId>cargo-maven2-plugin</artifactId>
	<version>1.0</version>
	<configuration>
		<container>
			<containerId>tomcat6x</containerId>
			<type>remote</type>
		</container>
		<configuration>
			<type>runtime</type>
			<properties>
				<cargo.remote.username>admin</cargo.remote.username>
				<cargo.remote.password>admin</cargo.remote.password>
				 <cargo.tomcat.manager.url>http://localhost:8080/manager</cargo.tomcat.manager.url>
				<cargo.servlet.port>8080</cargo.servlet.port>
			</properties>
		</configuration>
	</configuration>
</plugin>

同样需要在 settings.xml 中加入 pluginGroup：org.codehaus.cargo

3.3 执行cargo

运行 mvn clean package 命令,先打包
执行 mvn cargo:deploy 即可部署