由于要测试的程序集比较多，采用这种并行方式可以极大地提高运行效率。由于单元测试彼此是独立的，在并行运行时，互相没有干扰。这是我们实现判断的结果。一切看起来很美好，但在真正运行时，却出现了大量的死锁。异常信息为：

Transaction (Process ID) was deadlocked on resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

在我们的单元测试中，大多数测试需要访问的资源都是在内存中进行，但有一部分单元测试必须与数据库通信，对数据表进行读写。除了极少数特殊的测试用例外，对数据表的操作都放在事务中进行，并在执行完毕后，通过回滚事务，避免对真实数据的提交，保证单元测试不会影响数据库。

注：单元测试应该访问数据库吗？这其实还有待确认。在《修改代码的艺术》一书中，Feathers这样写道：

单元测试运行得快。运行得不快的不是单元测试。

有些测试容易跟单元测试混淆起来。譬如下面这些测试不是单元测试：

（1）跟数据库有交互；

（2）进行了网络间通信；

（3）调用了文件系统；

（4）需要你对环境作特定的准备（如编辑配置文件）才能运行的。

以上可以看到Feathers的态度是单元测试不应与外部资源进行交互。显然，如果出现了这些交互，应该采用Mock的方式来模拟对外部资源的访问。然而，某些实现功能却是与外部资源息息相关，又或者我们测试的目的本身是验证对外部资源的访问是否正确。从测试的范围来看，它们仍然算是单元测试，但因其特殊性，而应该将这些测试放到系统测试的范畴。在持续集成中，我们常常用金字塔来表示单元测试、系统测试和集成测试的数量。如下图所示：

单元测试的数量多，如果还需要访问外部资源，会严重影响运行单元测试的速度。关于单元测试、Mock等内容，我希望在以后的文章里详细论述。

在我们的项目中，是通过注入Fixture的形式生成测试数据。例如，我们可能希望注入Client、Associate等对象，从而完成对某些行为的测试。例如：

[Fixture(typeof(client_hastings))]
public Client client;

[Fixture(typeof(Samuel))]

public Associate Samuel;

通过Fixture准备数据时，如果采用了持久化方式，则意味着需要对数据表进行操作。如上代码可能操作多张表，例如对Client表和Associate表进行写操作。由于单元测试采用并行方式进行。假设存在两个单元测试均需要对Client和Associate注入Fixture，生成测试数据；并且不幸的是，这两个测试用例准备数据的顺序刚好相反，即A测试用例的顺序为Client->Associate，B测试用例的顺序为Associate->Client，可能发生死锁。

为什么？让我们分析数据库发生死锁的情况。它必然是多个进程（或线程）对两个或两个以上的资源形成了交叉访问。例如进程A在占有了资源1的同时，还需要访问资源2；与此同时，进程B在占有了资源2的同时，需要访问资源1。由于资源1已经被进程A占用，无法释放，进程B会等待；而进程A希望访问的资源2又被等待中的进程B持有；二者互不相让，终产生死锁。这正是并行运行单元测试导致死锁的根本原因。我们可以运行SQL Server Profiler来监视数据库的执行。注意，倘若需要跟踪死锁的情况，需要在Trace Properties中勾选“Deadlock Graph”和“Lock： Deallock”选项，如下图所示：

创建Trace后，利用并行方式运行单元测试，可能得到这样的Deadlock graph：

图中，椭圆代表进程（线程），矩形代表资源。左边的椭圆打了一把叉，说明是竞争失败的进程（线程）。从椭圆出发，箭头所指的资源，代表进程请求的资源；而发出箭头的资源，则代表箭头指向的进程持有该资源。可以发现，两个进程与两个资源之间的箭头，事实上形成了一个封闭的环。这正是死锁的典型表现。

当我们将单元测试的Fixture注入顺序保持一致时，这样的死锁能够避免了。这是一种限制，它很难被编写单元测试的开发人员所接受，即使勉强接受，仍然很容易疏漏。因此，我们的结论仍然是“不到迫不得已，单元测试不要访问外部资源”。或者说，我们可以将访问外部资源的单元测试，看成是特殊的单元测试，如果确实需要并行运行测试，以提高测试效率，可以通过引入多个Agent，以物理方式隔离资源，避免出现资源的争用导致死锁。

那么，这是否意味着我们的产品代码不够严谨，没有充分考虑并发的情况呢？不完全对。因为这里产生死锁的时机发生在准备测试数据的阶段，实际操作时，一般不会出现这种频繁对多张表进行操作的情况。然而，即使几率很低，始终存在死锁的隐患，这为我们的开发敲响了警钟。因此在开发过程中，有必要通过对业务的分析，制订一些指导原则，通过规范写数据表操作的顺序，避免出现死锁。这是这次并行运行单元测试给我们带来的启示。