我一直在我的代码库上使用NDepend，虽然我的实际代码似乎很顺利，但我的单元测试代码可能需要做很多工作。NDepend提出的一个建议是，由于测试之间的高度分离，将我的许多单元测试类转换为静态类。这似乎确实有助于避免在测试之间共享状态，并允许它们以任何顺序进一步运行。我应该将单元测试类转换为静态类吗？
同一TestFixture中的测试方法之间的共享状态，当然还有TestFixtures之间的共享
如果您的测试不需要按特定顺序运行，或者它们不依赖于初始值设定项代码，则可以使它们成为静态的。
请记住，这不是成功的秘诀。
有趣！我以前从未见过有人将NDepend分析应用于测试项目。虽然单元测试应该被视为代码库的第一类公民，但它们通常不会与应用程序一起部署，因此也不会受到相同的体系结构约束（FxCop、NDepend等）。在某种程度上，我同意这种方法，测试的质量需要验证，但我看不出一个工具除了识别类耦合问题之外还能提供什么好处，这些问题也会在生产代码中识别出来。
关于NUnit，它通常为该测试类中的所有测试方法实例化testfixture的单个实例。状态是测试之间共享的，这有好有坏。
好：在设置测试夹具时，可以设置需要时间才能创建的状态。
坏：应该在测试之间重置的状态由您在测试之间修复。
如果NUnit支持测试的静态方法，并且如果您需要测试夹具中的任何状态，那么这些字段将需要是静态的。这真的很可怕，因为在测试appDomain的整个生命周期中，测试的状态都是共享的。
关键是使用NUnit属性进行fixture和测试初始化/拆卸。永远不要使用构造函数或终结器进行fixture初始化，因为您无法控制NUnit框架何时创建您的类。