tdd - NUnit 最佳实践

Question

环境:(Visual Studio Professional 2008 中的 C# WinForms 应用程序)

我一直在挖掘有关 NUnit 最佳实践的指导。作为在相对孤立的环境中工作的独立程序员，我希望这里的集体智慧可以帮助我。

Scott White 有几个很好的起点 here但我不确定我是否完全同意他所说的一切——尤其是第 2 点。我的直觉告诉我，测试越接近被测试的代码，你就越有可能获得完整的测试覆盖率。在 Scott 的博客帖子的评论中，有人认为仅测试公共(public)接口(interface)是最佳实践，但我认为测试框架不是典型的类消费者。

您可以推荐什么作为 NUnit 的最佳实践？

Answer 1

如果第 2 点，你的意思是“每个解决方案的 bin 文件夹”——我明白你的意思。就个人而言，我会简单地添加对每个测试项目的引用。另一方面，如果您的意思是(1b)“不要将您的测试与您的代码放在同一个程序集中”，我衷心同意他的观点，但不同意您的观点。您的测试应该与您的生产代码不同，以提高代码的清晰度和组织性。保持你的测试类分开有助于下一个程序员更容易理解它。如果您需要在您的测试中访问内部——并且您可能因为内部方法对程序集是“公共(public)的”，您可以使用 Assembly.cs 文件中的 InternalsVisibleTo 构造。

我也建议，一般来说，只对代码的公共(public)接口(interface)进行单元测试就足够了。正确完成(使用 TDD)，您的代码的私有(private)方法将只是对先前公共(public)代码的重构，并且将通过公共(public)方法具有足够的测试覆盖率。当然，这是一个指导方针而不是法律，因此有时您可能想要测试私有(private)方法。在这些情况下，您可以创建访问器并使用反射来调用私有(private)方法。

我要提出的另一个建议是同时使用单元测试和代码覆盖率。代码覆盖率可以作为一种有用的启发式方法来确定何时需要更多测试。应使用缺乏覆盖作为指导，以指示可能需要更多测试的地方。这并不是说您需要 100% 的覆盖率——某些代码可能足够简单，不需要进行单元测试(例如自动属性)，并且您现有的测试可能不会触及它们。

我对这篇文章有几个问题。最大的可能是缺乏对单元测试数据库的抽象。可能有一些集成测试需要针对数据库进行 - 如果您无法说服自己相信它们的正确性，则可能是在测试触发器或约束功能时。不过，总的来说，我认为您应该将数据访问实现为接口(interface)，然后在单元测试中模拟出实际的实现，这样就不需要实际连接到数据库。我发现我的测试运行得更快，因此当我这样做时我会更频繁地运行它们。构建“假”数据库接口(interface)可能需要一点时间，但只要您坚持使用相同的数据访问设计模式，就可以重复使用。

最后，我建议将 nUnit 与 TestDriven.Net 一起使用。 - 一个非常有用的插件，无论你是在做 nUnit 还是 MSTest。使用右键单击上下文菜单可以非常方便地运行或调试测试。