NUnit 最佳实践 [英] NUnit best practice

问题描述

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

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

I've been digging around a little for guidance on NUnit best practices. As a solo programmer working in a relatively isolated environment I'm hoping that collective wisdom here can help me.

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

Scott White has a few good starting points here but I'm not sure I totally agree with everything he's said -- particularly point 2. My instincts tell me that the closer a test is to the code being tested the more likely you are to get complete test coverage. In the comments to Scott's blog posting is a remark that just testing the public interface is considered best practice by some, but I would argue the test framework is not a typical class consumer.

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

What can you recommend as best practices for NUnit?

推荐答案

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

If by point 2, you mean the "bin folder per solution" -- I can see your point. Personally, I would simply add the reference to each test project. If, on the other hand, you really mean (1b) "don't put your tests in the same assembly as your code" I heartily agree with him and disagree with you. Your tests should be distinct from your production code in order to enhance code clarity and organization. Keeping your test classes separate helps the next programmer understand it more easily. If you need access to internals in your tests -- and you might since internal methods are "public" to the assembly, you can use the InternalsVisibleTo construct in the Assembly.cs file.

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

I, too, would recommend that, in general, it is sufficient to unit test only the public interface of the code. Done properly (using TDD), the private methods of your code will simply be refactorings of previous public code and will have sufficient test coverage through the public methods. Of course, this is a guideline not a law so there will be times that you might want to test a private method. In those instances, you can create an accessor and use reflection to invoke the private method.

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

Another recommendation that I would make is to use unit testing and code coverage in tandem. Code coverage can be a useful heuristic to identify when you need more tests. Lack of coverage should be used as a guide to indicate where more testing may be needed. This isn't to say that you need 100% coverage -- some code may be simple enough not to warrant a unit test (automatic properties, for instance) and they may not be touched by your existing tests.

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

There were a couple of issues that I had with the article. Probably the biggest is the lack of abstraction away from the database for unit tests. There probably are some integration tests that need to go against the db -- perhaps when testing trigger or constraint functionality if you can't convince yourself of their correctness otherwise. In general, though, I'm of the opinion that you should implement your data access as interfaces, then mock out the actual implementations in your unit tests so that there is no need to actually connect to the database. I find that my tests run faster, and thus I run them more often when I do this. Building up a "fake" database interface might take a little while but can be reused as long as you stick with the same design pattern for your data access.

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

Lastly, I would recommend using nUnit with TestDriven.Net - a very useful plugin whether you're doing nUnit or MSTest. Makes it very handy to run or debug tests with a right-click context menu.

这篇关于NUnit 最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！