《xUnit Test Patterns》学习笔记5 - xUnit基础

这几节我看的比较快一些，因为内容之间其实是有联系的，所以合在一起做一个笔记。6-10节主要介绍了什么是Fixture，如何保证一个Fresh Fixture，如何使用Setup，Tearndown，如何进行验证(Verify)，等等。

什么是Fixture？

The test fixture is everything we need to have in place to exercise the SUT.

从作者的英文解释来看，Fixture确实是一个比较难定义的东西，所以作者用了everything这个词。

什么是Fresh Fixture？

一个测试案例一般都包含以下几个步骤：

1. Setup
2. Exercise
3. Verify
4. Teardown

Fresh Fixture是指每个案例执行时，都会生成一个全新的Fixture，好处是不受其他案例的影响。避免了Interacting Tests(之前有提到的)。

什么是Setup？

Setup是案例的准备阶段，主要有三种实现方式：In-line Fixture Setup, Delegated Setup, Implicit Setup。推荐使用的是Implicit Setup。

In-line Fixture Setup

直接在测试方法内部做一些具体的Setup操作 ：

缺点是容易造成很多重复的代码，不易维护。

Delegated Setup

相比In-line Fixture Setup，将里面具体的Setup操作提取出来，作为一个公用的方法，提高了复用性。

Implicit Setup

几乎所有的xUnit家族的框架都支持SetUp，比如，使用Google Test中指定的函数名SetUp，NUnit使用[Setup]Attribute。这种方法，不需要我们自己去调用Setup方法，框架会在创建Fresh Fixture后调用Setup。因此，我们只管实现SetUp方法。

什么是Teardown？

为了保证每个案例都拥有一个Fresh Fixture，必须在案例的结束时做一些清理操作，这就是Teardown。和Setup一样，Teardown也有三种实现方式：In-line Fixture Teardown, Delegated Teardown, Implicit Teardown。同样，推荐使用Implicit Teardown。

什么是Shared Fixture？

多个测试方法共用一个Fixture，这时，Setup只会在第一个测试方法执行时被执行。gtest中，同时还拥有一个公共的TearDownTestCases方法。

Result Verification

前面说过，测试案例必须拥有Self-Checking的能力。Verification分两种：State Verification和Behavior Verification。

State Verification

执行SUT后，验证SUT的状态：

验证时，可以使用Build-in Assertions，比如xUnit框架提供的assertTrue, assertEquals等方法。或者Custom Assertion等等。

Behavior Verification

不仅仅验证SUT的状态，同时还对SUT的行为对外部因素造成的影响进行验证。

比如下面这个例子：

除此之外，我们还可以使用一些Mock框架，使用基于行为的验证方式，这种方式，不需要我们显式的调用验证的方法。(Expected Behaivor Specification)

如何使测试代码变得简洁，减少重复？

Expected Object

需要比较对象内部很多属性时，使用对象比较会更简单。

原有案例代码：

改进后：

 

Custom Assersions

需要验证的细节很多时，可以自己定义一个Assersion，隐藏掉这些细节。比如：

 

Verification Methods

和Custom Asserions很像，唯一不同的是，Custom Assertion只包含验证的代码，Verification Methods同时还包含对SUT的操作。比如：

 

Parameterized and Data-Driven Tests

对于测试逻辑一致，只是测试数据有不同的测试案例，适合使用参数化测试，或者叫数据驱动测试。比如，Google Test就很好的提供了参数化的测试，见：

玩转 Google开源C++单元测试框架Google Test系列(gtest)之四 - 参数化

通过参数化，可以简化测试代码，不需要为大量不同的输入数据分别编写测试案例。

Avoiding Conditional Test Logic

验证时，不要使用一些条件相关的逻辑！比如，不要使用if, loop之类的语句！下面是一个例子：

使用if的情况：

可以看出，上面的写法是不好的，验证中有逻辑判断意味着有可能案例不够单一，使得案例难以理解。因此，比较好的是改成下面的方式：

 

Working Backward

一个编写测试案例的小技巧或者说是习惯吧，就是实现一个测试案例时，从最后一行开始写起，比如，先写Assertions。可以一试。

Using Test-Driven Development to Write Test Utility Method

我们经常实现一些测试用的辅助方法，这些方法在实现过程中，使用TDD的方式去实现，编写一些简单的测试案例，保证辅助方法也是正确的。也就是说，测试案例代码本身也是需要被测试的。

[温馨提示]：该文章由原博客园导入而来，如排版效果不佳，请移步：http://www.cnblogs.com/coderzh/archive/2010/01/24/xUnit-Test-Patterns-5.html