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

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


当前回答

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

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

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

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

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

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

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

其他回答

如果你正在考虑MSTest或NUnit,那么我建议你看看MbUnit。我的理由是

TestDriven.Net compatibility. Nothing beats have TestDriven.Net.ReRunWithDebugger bound to a keyboard combination. The Gallio framework. Gallio is a test runner like NUnit's. The only difference is it doesn't care if you wrote your tests in NUnit, MSTest, xUnit or MbUnit. They all get run. Compatibility with NUnit. All features in NUnit are supported by MbUnit. I think you don't even need to change your attributes (will have to check that), just your reference and usings. Collection asserts. MbUnit has more Assert cases, including the CollectionAssert class. Basically you no longer need to write your own tests to see if two collections are the same. Combinatorial tests. Wouldn't it be cool if you could supply two sets of data and get a test for all the combinations of data? It is in MbUnit.

我最初选择MbUnit是因为它的[RowTest ....我找不到一个回去的理由。我把我所有的活动测试套件从NUnit移过来,再也没有回头。从那时起,我已经将两个不同的开发团队转换为收益。

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

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

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

我收到消息说“NUnit文件结构比VSTest更丰富”… 当然,如果你更喜欢NUnit的文件结构,你可以使用这个解决方案的另一种方式,像这样(NUnit→Visual Studio):

 #if !MSTEST
     using NUnit.Framework;
 #else
     using Microsoft.VisualStudio.TestTools.UnitTesting;
     using TestFixture = Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAttribute;
     using Test = Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute;
     using SetUp = Microsoft.VisualStudio.TestTools.UnitTesting.TestInitializeAttribute;
     using TearDown = Microsoft.VisualStudio.TestTools.UnitTesting.TestCleanupAttribute;
 #endif

或任何其他转换…:-)这里的用法只是编译器的别名。

Daok列出了Visual Studio 2008测试项目的所有优点。下面是NUnit的优点。

NUnit has a mocking framework. NUnit can be run outside of the IDE. This can be useful if you want to run tests on a non-Microsoft build server, like CruiseControl.NET. NUnit has more versions coming out than visual studio. You don't have to wait years for a new version. And you don't have to install a new version of the IDE to get new features. There are extensions being developed for NUnit, like row-tests, etc. Visual Studio tests take a long time to start up for some reason. This is better in Visual Studio 2008, but it is still too slow for my taste. Quickly running a test to see if you didn't break something can take too long. NUnit with something like Testdriven.Net to run tests from the IDE is actually much faster. Especially when running single tests. According to Kjetil Klaussen, this is caused by the Visual Studio testrunner. Running MSTest tests in TestDriven.Net makes MSTest performance comparable to NUnit.