单元测试之道 笔记

注：参考网络上已存在的文章。

第1章 序言

 

·什么是单元测试

单元测试是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。

 A unit test is a piece of code writtern by a developer that exercises a very small, specific area of functionality of the code being tested.

·为什么要使用单元测试

单元测试不但会使你的工作完成得更轻松，而且会令你的设计变得更好。甚至大大减少你花在调试上面的时间。

Unit testing will make your life easier. It will make your designs better and drastically reduce the amount of time you spend debugging.

the heart of unit testing: the single most effective technique to better coding.

 

·如何进行单元测试

 guideline：

1^st，To decide how to test the method in question.

2^nd, run the test or all the tests.

·不写测试的借口

编写单元测试太花时间了

运行测试的时间太长了

测试代码并不是我的工作

我并不清楚代码的行为，所以也就无从测试

但是这些代码都能够编译通过

公司请我来试我是为了写代码，而不是写测试

如果我让测试员或者QA人员没有工作，那么我会觉得很内疚

我的公司并不会让我在真实系统中运行单元测试

第2章 你的首个单元测试

2.1 计划单元测试

2.2 运行单元测试

 

第3章 使用JUnit编写测试

 

3.1 构建单元测试

  习惯：测试方法以test开始

  测试代码必须要做以下几件事情：

·准备测试所需要的各种条件（创建所有必须的对象，分配必要的资源等等）。

·调用要测试的方法。

·验证被测试方法的行为和期望是否一致。

·完成后清理各种资源。

 

3.2 JUnit的各种断言

  JUnit提供了一些辅助函数，用于帮助你确定某个被测试函数是否工作正常。通常而言，我们把所有这些函数统称为断言。断言是单元测试最基本的组成部分。

  当一个失败或错误出现的时候，当前测试方法的执行流程将会被种植，但是（位于同一个测试类中的）其他测试将会继续运行。

 

 · assertEquals

assertEquals([String message],

expected,

actual)

 

assertEquals([String message],

expected,

actual,

tolerance)

 

 

·assertNull

assertNull([String message], java.lang.Object object)

assertNotNull([String message], java.lang.Object object)

 

 

 

·assertSame

assertSame([String message], expected, actual)

 

 

assertNotSame([String message], expected, actual)

 

 

 

·assertTrue

assertTrue([String message], Boolean condition)

 

 

asserTrue(true);

 

 

assertFalse([String message], Boolean condition)

 

 

·fail

fail([String message])

上面的断言将会使测试立即失败，其中message参数是可选的。这种断言通常被用于标记某个不应该被到达的分支（譬如，在一个与预期发生的异常之后）。

 

 

·使用断言

一般而言，一个测试方法会包含有多个断言，因为你需要验证该方法的多个方面以及内在的多种联系。

当有测试失败的时候，无论如何都不能给原有代码再添加新的特性！此时你应该尽快地修复这个错误，直到让所有的测试都能顺利通过。

 

 

3.3 JUnit框架

每个包含测试的类都必须如所示那样由TestCase继承而来。基类TestCase提供了我们所需的大部分单元测试功能，包括所有在前面讲述过的断言方法。

基类需要一个以String为参数的构造函数，因而我们必须调用super以传递这么一个名字。

测试类包含了名为test…的方法。而所有以test开头的方法都会被JUnit自动运行。你还可以通过定义suite方法制定特殊的函数来运行。

 

 

3.4 JUnit测试的组成

一个测试类包含一些测试方法；每个方法包含一个或者多个断言语句。但是测试类也能调用其它测试类：单独的类、包、甚至完整的一个系统。可以通过创建test suite来取得。任何测试类都能包含一个名为suite的静态方法。

public static Test suite();

你可以提供suite()方法来返回任何你想要的测试集合（没有suite()方法，JUnit会自动运行所有的test…方法）。但是你可能需要手工添加特殊的测试，包括其他suite。

 

 

· Per-method的Setup和Tear-down

JUnit的TestCase基类提供两个方法供你改写，分别用于环境的建立和清理：

protected void setup();

protected void teardown();

 

 

· Per-suite Setup和Tear-down

一般而言，你只须针对每个方法设置运行环境；但是在某些情况下，你须为整个test suite设置一些环境，以及在test suite中的所有方法都执行完成后做一些清理工作。要达到这种效果，你需要per-suite setup和per-suite teardown。

Per-suite的setup要复杂一些。你需要提供所需测试的一个suite（无论通过什么样的方式）并且把它包装进一个TestSetup对象。

注意你可以在同一个类中同时使用per-sutie和per-test的setup()和teardown。

 

 

3.5 自定义JUnit断言

如果你有需要在整个项目中共享的断言或者公共代码，你也许需要考虑从TestCase继承一个类并且使用这个字类来进行所有的测试。

事实上，开始新项目时总是从自己的自定义基类继承而不直接从JUnit的类继承通常是一个好主意——即便你的基类在一开始没有添加任何额外的功能。这样做的好处是当你需要添加一个所有测试类都需要的方法或者能力时，可以简单地编辑你的基类而不需要改动项目中的所有test case。

 

 

3.6 JUnit和异常

对于测试而言，下面两种异常是我们可能会感兴趣的：

1．  从测试代码抛出的可预测异常。

2．  由于某个模块（或代码）发生严重错误，而抛出的不可预测异常。

fail():提示这个地方应该出现异常。

 

任何对assertTrue(true)的使用都应该被翻译为“我预期控制流程会达到这个地方”。这对将来可能的误解来说会起到强有力的文档的作用。然而，不要忘记一个assertTrue(true)没有被调用不会产生任何错误的。

通常而言，对于方法中每个被期望的异常，你都应该写一个专门的测试来确认该方法在应该抛出异常的时候确实会抛出异常。

对于处于出乎意料的异常，你最好简单的改变你的测试方法的声明让它能抛出可能的异常。JUnit框架可以捕获任何异常，并且把它报告为一个错误，这些都不需要你的参与。

 

 

3.7 关于命名的更多说明

如果编写了一个测试，但是实现代码还没有准备好，可以将以“test”打头的测试方法名米功能为别的，譬如把“test”去掉，然后等准备好了要来运行测试的时候再改回来。

无论如何，你要避免养成忽略“失败的测试结果”的习惯。

 

 

3.8 JUnit测试骨架

用JUnit写测试真正所需要的就三件事：

1．  一个import语句引入所有junit.framework.*下的类。

2．  一个extends语句让你的类从TestCase继承。

3．  一个调用super(string)的构造函数。

 

第四章 what to test: The Right-BICEP

Right-BICEP

Right – All the result right?

B – All the all boundary conditions correct?

       C: conformance

       O: Ordering

       R: Range

       R: Reference

       E: Existence

       C: Cardinatity

       T: Time

I – Can you check the reverse relationships ?

       即： function1(B)àA(正向)

               function2(A)àB(反向)

 

C – Can you cross-check results using other means ?

       即：function1(A)àB1

              function2(A)àB2

              assertTrue(B1,B2)

E – Can you force error conditions to happen ?

P – Are performance characteristics within bounds ?

 

第五章 Correct Boundary Conditions

 

第六章 Using Mock Object

    6.2 Mock Objects

l         The real object has nondeterministic behavior.

l         The real object is hard to set up

l         The real object has behavior that is hard to trigger.

l         The real object has slow

l         The test needs to ask the real object about how it was used

l         The real object does not yet exist.

             

第七章 Properties of Good Test

A-TRIP

A automatic

       调用测试自动化、检查结果自动化

T thorough

       bugs intends to clump together in problematic area

R Repeatable

I Independent

P Professional

       对于不可能出现bug的地方，就不需要unit test

 

第八章 Testing on a project

unit test 安放位置

保证提交的代码有一套完整的测试代码

持续集成

Test & Reviews

code and review in this order:

1. Write test cases and/or test code.

2. Review test cases and/or test code.

3. Revise test cases and/or test code per review.

4. Write production code that passes the tests.

5. Review production and test code.

6. Revise test and production code per review.

 

第九章 Design Issue

 

9.1 面向测试的设计

       关注点分离

9.2 为了测试而重构

9.3 测试类的不变性

       结构不变性

       数学不变性

       数据一致性

9.4 面向测试的设计

       编写测试先于代码，根据测试实现代码