并行运行单元测试的启示(2)

　　在我们的项目中，是通过注入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，以物理方式隔离资源，避免出现资源的争用导致死锁。

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

原文转自：http://www.uml.org.cn/Test/201204112.asp