05｜TDD中的测试（1）：状态验证为什么是主要的使用方式？
测试的基本结构
需要说明一下的是，测试上下文（Test Context）在很多文献中被称作测试夹具（Test Fixture）。
夹具是个隐喻，是木工或者其他制造过程中，用以固定待加工工件的器具（上图中，棕色部分看起来是不是“夹”住了待测系统）。当然，这种拿一个生僻概念来隐喻另一个生僻概念的操作，也是很迷了。我要不是因为做吉他学习了木工，也不明白为什么要叫 Fixture。抛开这个隐喻，直接称作测试上下文其实就简单易懂多了。
再多说一句，如果使用Fit系自动化测试工具（Fit、Fitness，甚至 concordion、selenium），Fixture 则表示驱动待测系统的交互接口，也叫 Driver。这也是为啥，Selenium 后来改叫 WebDriver 的原因。
言归正传，这四个阶段的主要作用是：
初始化。主要是设置测试上下文，从而使待测系统（System Under Test）处于可测试的状态。例如，对于需要操作数据库的后台系统，测试上下文包含了已经灌注测试数据的测试用数据库，并将其与待测系统连接。
执行测试。就是按照测试脚本的描述与待测系统互动。例如，按照功能描述，通过 API 对系统进行相应的操作。
验证结果。就是验证待测系统是否处于我们期待的状态中。例如，经过测试，数据库中的业务数据是否发生了期待中的改变。
复原。就是将测试上下文、待测系统复原回测试之前的状态，或者消除测试对于待测系统的副作用。例如，删除测试数据中的数据（通常是通过事务回滚）。
测试上下文的设置将直接影响编写测试的难度，以及维护测试的成本。
在测试的四个步骤中，验证结果是最核心的一步，也是最核心的技术。验证结果有两种方式：状态验证（State Verification）和行为验证（Behavior Verification）。
状态验证
状态验证是指在与待测系统交互后，通过比对测试上下文与待测系统的状态变化，判断待测系统是否满足需求的验证方式。
状态验证是一种黑盒验证，它将测试上下文与待测系统当作一个整体。当待测系统不存在内部状态，而通过作用于依赖组件（Depended On Component）达成功能的时候，我们会从依赖组件中获取状态，以验证待测系统。如下图所示：
对于测试环境中存在进程外组件的情况，问题就要复杂一些了。在这种情况下，增量状态验证（Delta Verification）是一种有效的手段：
在这个例子里，在每一个测试复原时，都使用了“drop-and-create”来清除数据库中的数据，从而消除状态累积。但如果因为种种原因（比如测试数据量很大），使得每次清除测试数据都变得不现实时，就可以使用增量状态验证来降低状态累积的影响。
