不过也有可能是因为刚接触TDD，所以有些概念产生了一些错误的印象，导致使用Check时也出现了问题，今天碰到的典型问题就是 checked fixture 和 CK_NOFORK 模式结合起来使用时产生。
Manual中是这么解释 checked fixture：
We may want multiple tests that all use the same Money. In such cases, rather than setting up and tearing down objects for each unit test, it may be convenient to add some setup that is constant across all the tests in a test case. Each such setup/teardown pair is called a test fixture in test-driven development jargon.
也就是说，当多个单元测试对象建立和销毁的方式是相同的时候，可以通过向测试用例 Test case（一个测试用例由多个单元测试 unit test 组成）添加一个 checked fixture，它需要传递一个 setup() 和一个 teardown() 用于对象的创建和销毁。通常会配合一个全局变量使用。这样每个单元测试在开始之前都会有该全局变量最初通过setup创建的状态，进而多个测试之间不会产生相互的干扰。
这个“全局变量”让我一开始完全误解了它的意思，还以为它一经创建，状态会一直保存倒最后所有的单元测试完成并通过teardown进行对象的销毁。我所理解的这个意思其实是 UNchecked fixture，对于checked fixture，manual中进一步说明：
Checked fixtures run once for each unit test in a test case, and so they should not be used for expensive setup.
对于每个单元测试（不是每个测试用例），都会在测试开始前进行对象的创建，然后测试完成以后，立即销毁，所以它一般完成的工作量不能太大。
我自己的测试代码中有一部分需要连续向对象进行一些相同操作，然后检测所有操作完成以后对象的状态。开始我按照自己误解的意思，模拟manual，创建了一个 loop test，结果这个loop test 每次的 loop 都是一个单独的单元测试，完全失去了我一开始需要的作用。
另外一个问题是 checked fixture 和 Check的两个工作模式有关 ：CK_FORK 和 CK_NOFORK。Check的默认工作模式是前者，也就是每个单元测试都会fork出一个单独的地址空间，这样单元测试之间的数据不会产生干扰。CK_NOFORK则会使用同一地址空间，这样可以用于程序出问题时方便调试使用，也是因为如此，我开始的时候就默认设置成 CK_NOFORK 模式，但是测试程序总是会出现一些奇怪的错误，后来仔细阅读manual以后，将模式改回 CK_FORK，这种问题也就没再发生了。
