我一直在挖掘一些关于NUnit最佳实践的指导.作为一个在相对孤立的环境中工作的独立程序员,我希望这里的集体智慧可以帮助我.
斯科特怀特有一些很好的起点here,但我不确定我完全同意他所说的一切 – 特别是第2点.我的直觉告诉我,测试越接近被测试的代码,你就越有可能获得完整的测试覆盖率在对Scott的博客评论中发表的评论是,仅仅测试公共界面被一些人认为是最佳实践,但我认为测试框架不是典型的类消费者.
你能推荐什么作为NUnit的最佳实践？
如果在第2点,你的意思是“每个解决方案的bin文件夹” – 我可以看到你的观点.就个人而言,我只想添加对每个测试项目的引用.另一方面,如果你的意思是(1b)“不要将你的测试与你的代码放在同一个程序集中”,我衷心地同意他并且不同意你的意见.您的测试应与您的生产代码截然不同,以提高代码清晰度和组织.保持测试类的独立性有助于下一个程序员更容易理解它.如果您需要在测试中访问内部 – 并且您可能因为内部方法对程序集是“公共”的,您可以在Assembly.cs文件中使用InternalsVisibleTo构造.我也会建议,一般来说,仅对代码的公共接口进行单元测试就足够了.正确完成(使用TDD),代码的私有方法将简单地重构以前的公共代码,并通过公共方法获得足够的测试覆盖率.当然,这是一个指导方针,而不是法律,所以有时你可能想要测试私有方法.在这些情况下,您可以创建一个访问器并使用反射来调用私有方法.
我要做的另一个建议是串联使用单元测试和代码覆盖.代码覆盖率可以是一种有用的启发式方法,可以在需要更多测试时识别.应该使用缺乏覆盖率作为指导,以指示可能需要进行更多测试的地方.这并不是说您需要100％的覆盖率 – 有些代码可能很简单,不能保证单元测试(例如自动属性),并且您现有的测试可能无法触及它们.
我在文章中遇到了一些问题.可能最大的问题是单元测试数据库缺乏抽象.可能有一些集成测试需要针对db – 可能在测试触发器或约束功能时,如果你不能说服自己的正确性.但是,一般情况下,我认为您应该将数据访问实现为接口,然后模拟单元测试中的实际实现,以便不需要实际连接到数据库.我发现我的测试运行得更快,因此当我这样做时,我会经常运行它们.构建“虚假”数据库接口可能需要一段时间,但只要您坚持使用相同的数据访问设计模式,就可以重复使用.
最后,我建议将nUnit与TestDriven.Net一起使用 – 这是一个非常有用的插件,无论你是在做nUnit还是MSTest.使用右键单击上下文菜单运行或调试测试非常方便.