加速Java应用开发速度3——单元/集成测试+CI——仅做我的记录学习（转载）

时间 2019-11-18

标签加速 java 应用开发速度单元集成测试我的记录学习转载栏目 Java 繁體版

原文原文链接

你们可能对以下情景比较熟悉：javascript

若是开发过SSH的web项目，启动服务器可能会比较慢，有的项目甚至须要1分多钟，甚至更多，这个启动时间的等待通常就浪费了；
在开发项目时，有些功能比较复杂，当时以为思路特清晰，可是过了一段时间后，本身也忘了，完善功能时频繁出现bug，下降开发速度；
在维护项目时，不知道本身修改的对仍是不对，是否存在隐患；维护速度降下来了；
若是开发一个不少人都使用的接口，典型的如用户系统，要保证好比升级时向下兼容；
在团队间协做时，有时候只定义好接口，对方尚未给实现，如何进行同步开发？

如上问题，估计只要是个开发人员，均可能遇到过；若是此时有了单元/集成测试，那咱们能很好的解决这些问题。（注：加下来若是没有特殊状况，不刻意强调单元测试/集成测试，即提到测试是指的是单元/集成测试）php

我从如下几个方面介绍测试：html

一、为何须要测试？java

二、如何进行测试？node

三、测试有哪些好处？python

四、一切都须要测试吗？mysql

一、为何须要测试？

测试的目的是什么？个人理解是：git

缩短发现问题到解决问题的速度；
给程序一个修改后能验证是否正确的保证；（回归测试）
若是是开源软件，咱们能够经过单元测试了解其是怎么使用的；好比我以前经过cglib的单元测试学习过cglib的使用；

因此若是你遇到如上问题，就须要写测试。写测试多是为了本身（一、2）；也多是为了帮助别人（3）。github

二、如何进行测试？

不少朋友不知道如何进行测试，其实测试很简单，别把它想复杂了，按照本身的想法测试每一个功能点是否正确便可。web

2.一、测试流程

单元测试流程

集成测试流程

能够看出，单元测试与集成测试惟一不一样点是一个调用依赖系统而一个不调用；由于单元测试是最小粒度的测试，如在Java中是测试一个类，不会测试依赖系统；而集成测试是会测试依赖系统的。

测试的步骤：

准备环境
调用被测系统
验证
清理环境

环境：也叫作夹具（fixture）或者固件，表示调用被测系统时须要准备/清理的数据等等；

被测系统：在Java中就是要测试的类，如UserService；

依赖系统：测试被测系统时，其依赖的部分，如UserDao；

测试用例：包含测试方法的类，里边有不少测试方法来测试被测系统。

接下来仔细看看各部分都作了哪些工做。

2.二、环境

环境，也叫作夹具（fixture），表示调用被测系统时须要准备/清理的数据等等；保证测试时环境是干净的，如不被以前的数据库数据影响；保证每次测试都是在干净/新鲜的环境中执行的。所谓干净的环境表示如当前测试不被以前测试插入/删除/修改的数据形成影响。在junit中可使用：

@Before（setUp）安装夹具或准备环境：在测试用例的每一个测试方法以前执行；好比建立新鲜的被测系统，单元测试时安装Mock的依赖系统；
@After（tearDown）卸载夹具或清理环境：在测试用例的每一个测试方法以后执行；好比数据库测试时回滚事务，删除数据；关闭文件；
@BeforeClass：在整个测试用例以前执行；
@AfterClass：在整个测试用例以后执行；

使用如上方法，而不是直接在测试方法中安装/卸载；是由于无论有没有异常，@After/@AfterClass都会执行，这样防止出现异常可能形成环境是不新鲜的问题。

若是你们使用spring test来测试数据库相关的系统，能够考虑使用@TransactionConfiguration来支持默认事务回滚，这样不会对现有系统形成影响。具体可参考《【第十三章】测试之 13.1 概述 13.2 单元测试 ——跟我学spring3》和《【第十三章】测试之 13.3 集成测试 ——跟我学spring3》

测试时必定要保证环境是干净/新鲜的，才能保证每次测试的结果是同样的。

2.三、被测系统与依赖系统

被测系统：在Java中就是被测试的Java类。

依赖系统：就是被测试Java类依赖的其余类。

若是是单元测试，通常状况下，会对依赖系统进行模拟（Mock），即给它一个假的实现；典型的如测试服务层时注入一个Mock的DAO层，这样的好处：

加快测试速度；由于不会调用真实的被测系统，因此速度特别快；
测试尚未完成的功能；尤为在多团队协做时，能够只在定义好接口的状况下开发系统；

若是是集成测试时，直接注入真实的依赖系统便可，好处：

完成联调；
发现本身的问题；
还可能发现本身使用上问题及使用的API的问题；

单元测试虽然好，可是是隔离测试，即不会调用被测系统来完成测试，由于不是真实的联调，因此极可能会潜在有一些问题，所以仍是须要集成测试。（因此不是很刻意分单元或集成测试，且有些系统可能只有集成测试）

可是集成测试速度是比较慢的，通常提交给CI执行，不影响当前开发进度。

2.四、验证

验证的目的：是保证明际结果和咱们预期的结果是否一致，说白了就是是不是咱们想的那样。

通常使用断言来验证，如：

Assert.assertEquals(expectedResult, actualResult); //验证预期结果和实际结果是否相等

验证主要有两种：

结果验证
行为验证

结果验证：即验证被测系统返回的结果是否正确，如：

Java代码

@Test
public void testCount() {
String ql = "select count(o) from User o";
long expectedCount = repositoryHelper.count(ql) + 1;
User user = createUser();
repositoryHelper.getEntityManager().persist(user);
long acutalCount = repositoryHelper.count(ql);
Assert.assertEquals(expectedCount, acutalCount);
}

验证返回的数据总数 = 插入以前的总数 + 1；即结果验证。此处咱们使用了一种叫作相对（delta）测试；即不关心数据库里到底多少条，只关心实际的和预期的差。

行为验证：即验证被测系统是否调用了依赖系统的某个API ，这个只有当咱们使用Mock时测试时比较简单，如当用户注册时：

一、加积分

二、发系统消息

三、……

此时咱们并不能经过结果验证是否调用了这些方法；那么咱们可使用Mock技术来完成验证是否调用了这些API，好比使用jmock测试框架就支持行为验证。集成测试是很难进行行为验证的，若是测试须要预留间谍接口。

三、测试有哪些好处？

咱们写代码的目的是正确的完成某个功能，如何保证正确呢？测试！因此在不使用如单元测试技术时，咱们也是须要测试，可是这个测试是咱们人工验证的。缺点很明显：

不是自动的，每次须要对比预期结果与实际结果，尤为数据量/逻辑复杂时更痛苦；
不是回归的，上次测试完成后，下次还得重复本身一遍；

为了解决这个问题，咱们使用如单元测试技术来解决这个问题：

测试自动化；即验证预期结果与实际结果交给计算机吧；
测试回归性，能够重复执行测试，验证修改后逻辑是否仍是正确的；

即测试的好处，从如上已经提炼出来了：

缩短发现问题到解决问题的时间；
重复使用测试，保证修改后的代码仍是正确的；
若是作开源项目，能够提供给使用人员参考如何使用；
由于单元测试都很是快，因此提高了开发速度；

四、一切都须要测试吗？

确定不是，一切都是相对的；哪些不须要测试呢：

你很是熟悉的功能；
一些简单的CRUD；
你认为不须要测试的；好比你颇有把握的东西，就没有必要浪费时间测试了；

哪些须要测试呢：

复杂的业务逻辑/系统核心功能，最典型的如订单系统：必定要有足够的单元测试保证，这是一个电商系统的核心；还有如用户系统、积分系统等等；
框架级别/工具级别/通用级别的代码须要测试，即提供给第三方使用的代码，由于这些代码可能被不少系统依赖，应该保证其正确性；并且还要保证之后版本升级的向下兼容；
你认为须要测试的，好比你没有把握的东西，仍是写点测试来缩短如开发web项目的重启系统的时间吧；

测试不是不耗时间的，没意义的测试就是浪费时间，最典型是一些书上的对一个增删改查进行测试，实际项目没有任何意义。因此你应该只对本身很难驾驭的以为有必要的代码进行测试。不要成为一个测试狂，什么都测试。

一些测试能够参考个人《es——JavaEE快速开发脚手架》中的代码。经过测试我获得了许多好处。

到此咱们介绍完成了测试，可是若是咱们使用了如集成测试时，测试执行起来可能比较慢，跑一遍测试可能须要5分钟，那怎么办呢？

天天下班前跑一遍集成测试，而后修复，下班走人；
CI：持续集成，交给持续集成服务器，自动地测试完成后把测试报告以邮件的形式发到开发人员邮箱；

------------------------------------分割线----------------------------------

接下来介绍一下CI吧。

一、为何须要CI

二、CI如何工做的

三、travis-ci介绍

一、为何须要CI

正如前边说的，咱们单独测试可能会遇到以下问题：

若是写了一个测试，就要把全部测试跑一遍看看整个系统是不是正确的，那么每次等待时间是很是漫长的；
若是团队中的其余成员改了功能并提交了，如何快速获得该次提交对当前系统代码是正确仍是失败的反馈；

那怎么办呢？自动化地持续集成（CI）！CI的核心就是干这件事情的。自动化持续地集成测试。

使用CI后，若是使用Maven，能够新建多个profile：

本地测试时忽略一些比较慢的测试；
CI服务器上执行全部测试；

二、CI如何工做的

一个典型的持续集成流程：

按期检测版本服务器上是否有代码更新；
若是发现代码更新，从版本服务器下载最新的代码；
自动构建并自动化的测试；
无论错误/失败，生成报告给开发人员；
有些CI服务器还能产生可执行的软件，自动化地部署到测试机器，交给测试人员测试。

如图所示：

持续集成服务器其实就是一个定时器，自动帮你下载最新代码、编译、测试、集成及产生报告发给开发人员。

常见的CI服务器有：

Apache Continuum
Hudson
CruiseControl
Jenkins CI
TeamCity
Travis CI

我09年时使用过TeamCity社区版，足够知足常见需求；目前我使用github托管项目，使用Travis CI进行分布式的持续集成，免费，目前看来仍是不错的。

三、travis-ci介绍

我如今开发的ES-JavaEE项目开发脚手架就是使用travis ci进行持续集成；具体参考《Getting started》进行与Github集成，其支持的语言：

支持的数据库：

MySQL
PostgreSQL
MongoDB
CouchDB
Redis
Riak
RabbitMQ
Memcached
Cassandra
Neo4J
ElasticSearch
Kestrel
SQLite3

更多请参考其官网的介绍。

若是是Java开发人员，支持的JDK包括：OpenJDK 和 OracleJDK。若是使用的是OpenJDK，Maven中使用ascii2native插件时，须要以下配置：

Java代码

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>native2ascii-maven-plugin</artifactId>
<version>1.0-alpha-1</version>
<executions>
<execution>
<phase>generate-resources</phase>
<goals>
<goal>native2ascii</goal>
</goals>
<configuration>
<encoding>UTF-8</encoding>
<src>src/main/messages</src>
<dest>target/${project.artifactId}/WEB-INF/classes</dest>
<includes>messages.properties</includes>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>1.7.0</version>
<scope>system</scope>
<systemPath>${java.home}/../lib/tools.jar</systemPath>
</dependency>
</dependencies>
</plugin>

若是使用mysql，端口只能是3306。

若是想开端口测试，这是不容许的。

以下是我项目中的一个配置.travis.yml，放到项目的根下便可：

-----------------------------------

language: java 语言

env: 环境

- DB=mysql 使用mysql

jdk:

- openjdk jdk使用openjdk

mysql:

database: es 数据库名为es

username: root 用户名为root

password : 密码为空

encoding: utf8 编码为utf8

install: 安装时执行的脚本

- mvn install -Dmaven.test.skip=true mvn安装并跳过测试

before_script: script以前执行的测试

- cd web

- mvn db:create 建立数据库的mvn命令（此处使用了 maven-db-plugin 插件）

- mvn db:schema 建立脚本的mvn命令

- mvn db:data 安装数据的mvn命令

- cd ..

script: 测试时执行的脚步

- cd common

- mvn test 测试common子模块

- cd ..

- cd web

- mvn test -Pit 测试web子模块，并指定使用it profile测试（即集成测试的配置，具体参考pom.xml中的profile/it）

notifications: 触发

email: 测试完成后测试报告发到哪

- zhangkaitao0503@gmail.com

-----------------------------------

持续集成不能修复代码的错误，而是和单元测试同样，缩短发现问题带解决问题的时间，这样能够提升开发效率，下降项目风险，提升项目的稳定性。并且尤为是团队协做时，能够发现其余人的代码是否对本身的代码产生影响。

到此咱们利用单元测试+CI能够加速开发人员的开发速度。利用好单元测试和CI，不要纯粹为了单元测试和CI而去作这些事情。

本文没有介绍TDD，TDD并不会那么美好，我认为咱们能够借鉴TDD的一些思想，但决不能迷信TDD，有时候，尤为如开发企业应用，先写功能再写测试可能效率更高，并且大部分时候是不须要TDD的。并且我也没能在实际项目中获取太多TDD的好处，可是我得到了测试的好处。

本文也没有介绍测试覆盖率，我认为不要一味的追求覆盖率，有时候有的覆盖率没有任何意义。因此不要让为了覆盖率而覆盖率拖慢了项目开发进度。

正如stackoverflow上的一篇帖子《How deep are your unit tests?》上Kent Beck的回答：

写道

老板为个人代码付报酬，而不是测试，因此，我对此的价值观是——测试越少越好，少到你对你的代码质量达到了某种自信。

能够前往coolshell的“单元测试要作多细？”去获得一些经验。