NUnit 最佳实践

环境：（Visual Studio Professional 2008 中的 C# WinForms 应用程序）

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

斯科特·怀特（Scott White）有一些很好的起点here http://scottwhite.blogspot.com/2008/05/nunit-best-practices.html但我不确定我是否完全同意他所说的一切——尤其是第 2 点。我的直觉告诉我，测试越接近正在测试的代码，就越有可能获得完整的测试覆盖率。在 Scott 博客文章的评论中，有人认为仅测试公共接口是最佳实践，但我认为测试框架不是典型的类使用者。

您可以推荐哪些 NUnit 最佳实践？

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

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

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

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

最后，我建议使用 nUnit测试驱动.Net http://testdriven.net/- 无论您是在进行 nUnit 还是 MSTest，这都是一个非常有用的插件。使用右键单击上下文菜单可以非常方便地运行或调试测试。