在这个 asp.net 中，我正在清理可能会发生死锁。我想确保代码正确处理它们，所以我正在尝试编写触发死锁的 NUnit 测试.....
DAO 按实体拆分。每个实体都有一组测试，它们被 Startup() 和 Teardown() 方法包围，这些方法创建一个事务范围，然后在测试完成后将其回滚。这对其他一切都很好，但对于死锁完全没用。
如何使用可以可靠复制的 TransactionScope 和 SQL2000（即涉及 MSDTC）设置和运行“死锁”测试？更多细节：我知道有一种情况，如果两个用户使用不同的、特定的数据值调用两个函数，那么可能会导致死锁。我怎样才能在 NUNIT 中模拟这个 - 并让死锁总是发生？
是的，我确实从“你为什么不首先阻止死锁发生”行动计划开始，但我无法控制可能发生死锁的代码 - 我只是调用函数，它们可以死锁.
如果您的死锁导致抛出异常，您希望使用 Mock 对象来模拟抛出的异常。
基本思想是您告诉您的 Mock Object 框架（我喜欢TypeMock）改为抛出异常，如下所示：
MockObject mo = MockManager.MockObject(typeof(MyDeadlockException));
mock.ExpectAndThrow("MyMethod", (MyDeadlockException)mo.Object);
其他模拟框架的想法基本相同。
如果您在交易过程中的一项测试只是“等待”了 5 分钟呢？或者，您只需编写一个启动事务的测试，创建一条新记录，然后在不提交的情况下更新该记录。然后，在其中启动一个新事务并尝试读取已创建且当前正在更新的记录。你会在那里陷入僵局。
如果您手动锁定了一个表并始终保持锁定状态怎么办？那么，您对该表采取的任何操作都会产生死锁情况吗？
遇到这种情况，但是否可以在您的 TestSetup 方法中实际创建到数据库的 SQLConnection？然后，使用它，您可以发出一个命令来锁定表或采取一些行动来锁定记录或页面？那样的话，它会在你正在进行的任何其他交易之外吗？不过，这似乎是您已经考虑过的一个选项。你的情况我错过了什么？
对于单元测试，您可能希望避免实际使用数据库。你怎么知道你有死锁。您应该测试告诉您存在死锁的条件并在测试中创建它。
如果您调用服务并返回错误，则模拟是模仿的理想方式。只需让模拟返回您期望的错误。如果您正在等待超时或其他东西，那么同样适用。
一般来说，单元测试应该只在被测试的代码上运行，而不是依赖于任何其他代码或组件。也就是说 - 数据库本质上是另一个组件，您可能正在使用 nunit 进行某种功能测试来驱动它们。
在这种情况下，您确实必须创建死锁情况，但锁定记录或表，然后调用尝试使用相同记录并处理响应的组件。