我将在工作中开始一个新项目,并想进入单元测试。我们将使用Visual Studio 2008, c#和ASP。NET MVC之类的东西。我正在考虑使用NUnit或Visual Studio 2008的内置测试项目,但我也愿意研究其他建议。是一种系统比另一种更好,还是比另一种更容易使用/理解?
我希望让这个项目成为我们未来发展努力的“最佳实践”。
我将在工作中开始一个新项目,并想进入单元测试。我们将使用Visual Studio 2008, c#和ASP。NET MVC之类的东西。我正在考虑使用NUnit或Visual Studio 2008的内置测试项目,但我也愿意研究其他建议。是一种系统比另一种更好,还是比另一种更容易使用/理解?
我希望让这个项目成为我们未来发展努力的“最佳实践”。
当前回答
我已经使用NUnit两年了。一切都很好,但是我不得不说Visual Studio中的单元测试系统非常好,因为它在GUI中,可以更容易地对私有函数进行测试,而不必搞得乱七八糟。
此外,Visual Studio的单元测试允许你做覆盖和其他NUnit单独不能做的事情。
其他回答
首先我想纠正一个错误的说法:你可以使用命令行在Visual Studio之外运行MSTest。尽管一些CI工具,如TeamCity,对NUnit有更好的支持(可能会随着MSTest变得更流行而改变)。
在我目前的项目中,我们两者都使用,唯一的大区别是,我们发现MSTest总是作为32位运行,而NUnit运行为32位或64位测试,这只在你的代码使用32/64位依赖的本机代码时才重要。
我不喜欢Visual Studio的内置测试框架,因为它迫使你创建一个单独的项目,而不是把你的测试作为你正在测试的项目的一部分。
单元测试框架实际上并不重要,因为你可以用单独的项目文件和条件编译转换测试类(就像这样,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中,您可以直接从正在测试的类中运行测试。毕竟,单元测试应该易于维护,并且离开发人员很近。
我更喜欢使用MS的小测试框架,但现在我坚持使用NUnit。多发性硬化的问题通常是(对我来说)
必须维护的共享“测试”文件(无意义) 测试列表会与多个开发人员/ vcs产生冲突 糟糕的集成UI -令人困惑的设置,繁重的测试选择 没有好的外部流道
警告
如果我正在测试一个aspx站点,我肯定会使用MS的 如果我是独自开发,MS也可以 如果我的技能有限,不能配置NUnit:)
我发现编写我的测试并启动NUnitGUI或其他前端(testDriven的价格非常非常非常昂贵)要容易得多。使用命令行版本设置调试也非常简单。
随着。net 4.0中代码契约系统的发布和静态检查器的可用性,理论上你将需要编写更少的测试用例,而像Pex这样的工具将有助于识别这些用例。将这一点与前面的讨论联系起来,如果您需要更少地使用单元测试,因为您的契约会覆盖您的尾部,那么为什么不直接使用内置组件呢,因为这样可以少管理一个依赖项。这些天来,我只追求简单。: -)
参见:
微软Pex -自动化单元测试 使用Visual Studio 2010和c# 4.0与Pex生成单元测试