NUnit最佳实践

Question

环境：(2008中的C# WinForms应用程序)

我一直在研究一些关于NUnit最佳实践的指南。作为一个单独的程序员，在一个相对孤立的环境中工作，我希望这里的集体智慧能帮助我。

Scott有几个很好的起点-- 这里，但我不确定我完全同意他所说的一切--尤其是第2点。我的直觉告诉我，测试越接近被测试的代码，就越有可能获得完整的测试覆盖率。在Scott博客上的评论中，有人认为仅仅测试公共接口是最佳实践，但我认为测试框架并不是典型的类使用者。

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

Answer 1

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

我也建议，一般来说，只对代码的公共接口进行单元测试就足够了。正确地执行(使用TDD)，您的代码的私有方法将仅仅是对以前的公共代码的重构，并将通过公共方法具有足够的测试覆盖率。当然，这是一个指南，而不是法律，所以有时您可能想要测试一个私有方法。在这些实例中，可以创建访问器并使用反射调用私有方法。

我要提出的另一个建议是同时使用单元测试和代码覆盖。当您需要更多的测试时，代码覆盖率可能是一种有用的启发式识别方法。应以缺乏覆盖范围作为指南，指出可能需要进行更多测试的地方。这并不是说您需要100%的覆盖率--一些代码可能足够简单，不值得进行单元测试(例如，自动属性)，并且它们可能不会被现有的测试所触及。

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

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

Answer 2

我的直觉告诉我，测试越接近被测试的代码，就越有可能获得完整的测试覆盖率。在Scott博客上的评论中，有人认为仅仅测试公共接口是最佳实践，但我认为测试框架并不是典型的类使用者。

如果您的代码不能仅使用公共入口点进行测试，那么您就会遇到设计问题。您应该更多地了解TDD和固体原理 (特别是单责任原则和依赖反转)。然后，您将了解到，遵循TDD方法将帮助您编写更可测试、更灵活和更易于维护的代码，而无需使用诸如测试类的私有部件之类的“黑客”。

我还强烈推荐阅读谷歌可测试性指南( Miško Hevery )，它有很多涵盖这些主题的代码示例。

Answer 3

我的情况非常相似，这个问题描述了我做什么keep-your-source-close-and-your-unit-tests-closer。没有太多的人对我的方法着迷，但它对我来说是完美的。