我将在工作中开始一个新项目,并想进入单元测试。我们将使用Visual Studio 2008, c#和ASP。NET MVC之类的东西。我正在考虑使用NUnit或Visual Studio 2008的内置测试项目,但我也愿意研究其他建议。是一种系统比另一种更好,还是比另一种更容易使用/理解?

我希望让这个项目成为我们未来发展努力的“最佳实践”。


当前回答

随着。net 4.0中代码契约系统的发布和静态检查器的可用性,理论上你将需要编写更少的测试用例,而像Pex这样的工具将有助于识别这些用例。将这一点与前面的讨论联系起来,如果您需要更少地使用单元测试,因为您的契约会覆盖您的尾部,那么为什么不直接使用内置组件呢,因为这样可以少管理一个依赖项。这些天来,我只追求简单。: -)

参见:

微软Pex -自动化单元测试 使用Visual Studio 2010和c# 4.0与Pex生成单元测试

其他回答

单元测试框架实际上并不重要,因为你可以用单独的项目文件和条件编译转换测试类(就像这样,Visual Studio→NUnit):

 #if !NUNIT
  using Microsoft.VisualStudio.TestTools.UnitTesting;
 #else
  using NUnit.Framework;
  using TestClass = NUnit.Framework.TestFixtureAttribute;
  using TestMethod = NUnit.Framework.TestAttribute;
  using TestInitialize = NUnit.Framework.SetUpAttribute;
  using TestCleanup = NUnit.Framework.TearDownAttribute;
  using TestContext = System.String;
  using DeploymentItem = NUnit.Framework.DescriptionAttribute;
 #endif

TestDriven。Net插件很好,不是很贵…对于普通的Visual Studio 2008,你必须从你的测试类或测试列表中找到测试。TestDriven。Net中,您可以直接从正在测试的类中运行测试。毕竟,单元测试应该易于维护,并且离开发人员很近。

xUnit是新项目的另一种可能。它的语法可能更直观,但它与其他框架并不兼容。

我不喜欢Visual Studio的内置测试框架,因为它迫使你创建一个单独的项目,而不是把你的测试作为你正在测试的项目的一部分。

我用这两种方法做过一些TDD,(也许我有点笨)NUnit对我来说似乎更快更简单。我说的很多,就是很多。

在MSTest中,到处都有太多的属性——真正进行测试的代码就是你可能在这里或那里读到的那些小行。一片混乱。在NUnit中,执行测试的代码只是控制属性,就像它应该做的那样。

同样,在NUnit中,你只需要点击你想要运行的测试(只有一个?一个班的所有测试?一个装配?解决方案?)一个点击。窗户又大又亮。你可以看到清晰的绿灯和红灯。你真了解一眼就能看到什么。

在VSTS中,测试列表卡在屏幕的底部,它又小又丑。你得仔细看看才能知道发生了什么事。而且您不能只运行一个测试(好吧,我还没有发现!)。

当然,我可能是错的——我刚刚读了21篇关于“如何使用VSTS做简单的TDD”的博文。我应该多读些书;你说得对。

在《NUnit》中,我读了一本。同一天我也去了tdd。与乐趣。

顺便说一下,我通常很喜欢微软的产品。Visual Studio确实是开发人员能买到的最好的工具——但是Visual Studio Team System中的TDD和工作项管理真的很糟糕。

Visual Studio测试框架的一个小麻烦是,它会创建许多测试运行文件,这些文件往往会使您的项目目录变得混乱——尽管这并不是什么大问题。

另外,如果你缺少一个像TestDriven这样的插件。NET,你不能在Visual Studio环境中调试你的NUnit(或MbUnit, xUnit等)单元测试,而你可以在Microsoft Visual Studio测试框架中进行,这是内置的。