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