单元测试手册

#规范,文档,流程规范,手册

1. 基础概念

软件测试作为软件质量的保障，有着十分重要的意义。按照不同的层次划分，测试也有着诸多的种类。按照测试方式分，有白盒测试、黑盒测试、灰盒测试。按照测试范围或流程来分，有单元测试、集成测试与系统测试等。其中，应用覆盖面最广、也是最为基础的就是单元测试。

单元测试（Unit Test）又被称为模块测试，是针对程序中最小可测试单元来进行测试的活动。一般来讲，在如今的软件开发工程中，是指对程序中方法（或称函数）的测试。通过为这个方法构造初始化的条件，并运行这个方法，看这个方法的行为是否与预期的一致，以此来决定该方法是否正常。

2. 单元测试的意义

2.1. 快速定位问题

单元测试的主要作用，就是将原本人工检查程序行为的方式，在最小可测单元范围内，用程序检测程序的方法来代替。为此，单元测试的主要作用就是定位问题。同时，由于单元测试的执行效率较高，可以大批量快速执行。这对于对于单元测试覆盖率较高的工程，若代码工程有任何问题，则可以快速执行全部单元测试，能够帮助开发者快速定位或排除问题。

2.2. 持续集成

目前的软件交付要求快速迭代与持续集成，在这样的团队中每一天都有代码合入，并且定期都会有新版本发布。在这一过程中，若使用单元测试覆盖软件各部分，在开发与集成的过程中不对代码进行测试，发现问题就立即告警，则可以提高软件质量与开发效率。

2.3. 优化软件设计与架构

单元测试并不是在代码开发完毕才开始撰写的，一般情况下都是与开发过程并行或者先与开发过程的。在这个过程中，为了构造可测试的接口与参数，自然会让开发者在软件设计时让程序趋于模块化，并且接口明确，层次清晰。这也就在无形中优化了软件的设计与架构。

2.4. 重构的保障

在重构代码时，可能会影响既有业务和功能，常常会为了解决一个问题而不慎引入更多问题。若有单元测试的覆盖，在重构时则有所保障，能够帮助开发者快速发现问题，提高重构效率。

3. 单元测试思路

开发者在未接触单元测试之前，往往无从下手。其实，单元测试代码的开发与普通程序的开发没有本质的差别。它的核心逻辑是：

通过这样一个模板或思路去理解单元测试，那就非常简单了。在现行的软件测试实践中，为了提高测试代码的开发效率，业界有着许多测试框架，利用这些测试框架，可以帮助开发者快速开发测试代码。为此，在进行单元测试前，需要根据自身的情况，对单元测试框架做一定的学习。但不管测试框架是怎样的，其核心思路都与上文讨论的一致。

4. 单元测试原则

单元测试原则常被概括为：FIRST，分别是：

快速（Fast）

单元测试应该能够被快速地执行完毕，执行效率低会让开发者不愿意运行。同时，单元测试需要在整个开发过程中执行很多次，过慢的运行速度会影响开发效率

用例独立（Independent）

单元测试用例之间应该相互独立，最好不要有关联，也不要有执行顺序的要求。

#错误示例

TestModel bean = TestModel.getInstance();
@Test
public void testDependent() {
	bean.add();
	Assert.assertEquals(bean.getIndex(), 1);
}
@Test
public void testDependent2() {
	bean.add();
	Assert.assertEquals(bean.getIndex(), 1);
}

#正确示例 当然也可以添加@before注解来实现

@Test
public void testDependent() {
	TestModel bean = new TestModel();
	bean.add();
	Assert.assertEquals(bean.getIndex(), 1);
}

@Test
public void testDependent2() {
	TestModel bean = new TestModel();
	bean.add();
	bean.add();
	Assert.assertEquals(bean.getIndex(), 2);
}

可重复（Repeatable）

单元测试不应该依赖于环境中的数据，它应该有自己的初始化数据或条件，每一次单元测试都是可重复的。

public class TestModel {

	int index;

	public int getIndex() {
		return index;
	}

	public TestModel() {
		init();
	}

	private void init() {
		index = 1;
	}

	public void setIndex(int index) {
		this.index = index;
	}

	public void add() {
		index++;
	}
}

#正确示例
 @Test
 public void testDependent() {
	 TestModel bean = new TestModel();
	 bean.setIndex(0);
	 bean.add();
	 Assert.assertEquals(bean.getIndex(), 1);
 }

 #错误示例
	@Test
 public void testDependent() {
	 TestModel bean = new TestModel();
	 bean.add();
	 Assert.assertEquals(bean.getIndex(), 1);
 }

因为index内部初始化无法控制.

可自验证的（Self-Validating）

单元测试应该不用人工检查，而是可以自验证的。不应通过System.out或日志之类的方式进行结果确认

#错误示例
@Test  
public void testCreate()  
{  
    String str = "file://user:123456@host/opt/config/test?value=1&value2=mytest";  
    Uri uri = Uri.create(str);  
    URI target = URI.create(str);  
  
    System.out.println(target.getScheme()+":"+uri.getScheme());  
    System.out.println(target.getPath()+":"+uri.getPath());  
    System.out.println(target.getUserInfo()+":"+uri.getUserInfo());  
    System.out.println(target.getUserInfo()+":"+uri.getUserInfo());  
  
    System.out.println(uri.queryKeys().size());  
}


#正确示例
@Test  
public void testCreate()  
{  
    String str = "file://user:123456@host/opt/config/test?value=1&value2=mytest";  
    Uri uri = Uri.create(str);  
    URI uri1 = URI.create(str);  
  
    Assert.assertEquals(uri1.getScheme(), uri.getScheme());  
    Assert.assertEquals(uri1.getPath(), uri.getPath());  
    Assert.assertEquals(uri1.getUserInfo(), uri.getUserInfo());  
    Assert.assertEquals(uri1.getUserInfo(), uri.getUserInfo());  
  
  
    Assert.assertEquals(2, uri.queryKeys().size());  
}

全面完整的（Thorough）

单元测试不应该追求每一个方法都覆盖到，而是应该追求所有的使用场景都全面完整的覆盖到。例如对边界条件，错误输入，大数据量的情况都要覆盖到。如果发现错误，请编写一个测试来发现它。然后，您可以通过调试测试来快速修复该错误。

可维护

  1. 遵循AAA规则：安排（Arrange），执行（ Action），断言（Assert

在单元测试方面，AAA代表Arrange，Action，Assert。这是编写单个测试以使其更具可读性和实用性的通用模式。

首先，您要安排。在这一步中，您将设置要测试的东西。您设置变量，字段和属性以使测试能够运行以及定义预期结果。

然后您采取行动-即，您调用要测试的方法。

最后，您断言——调用测试框架来验证您的“行为”的结果是否符合预期。遵循AAA原则，你的测试就会清晰易懂。

  1. 测试用例中尽量不要包含逻辑判断

  2. 通过测试公共方法来验证私有方法

不去直接测试private函数，好的private函数都应该是很小很简单的，测试那调用了private函数的public和protected方法即可。

或者，也许这个private函数其实应该被声明称protected。

  1. 不要使用try...catch...

  2. 追求 100% 的代码覆盖率性价比非常低,根据 2-8 原则，80% 的代码都是很好测试

  3. 不要滥用Mock

Mock在依赖隔离的同时，也使得测试场景逐渐偏离真实性，增加了测试风险

5. 单元测试分类

按照单元测试运行的环境区分，可以分为本地测试以及设备测试.

5.1. 本地测试

本地测试(Local unit test)运行在JVM中，一般适用于对于没有Android依赖的测试。该部分测试代码一般放置于安卓工程的<模块名>/src/test/java中。

5.2. 设备测试

设备测试（Instrumented test)运行在手机或模拟器中，一般适用于需要Android依赖的测试。该部分测试代码一般放置于安卓工程的<模块名>/src/androidTest/java中。

实际上，在这类测试过程中是编译了一个额外的Apk，并安装到手机或模拟器中运行的。

5.3. 测试框架选择

目前流行的Android测试框架较多，按照测试情况，可以分为：

6. 注意点