我将在工作中启动一个新项目,并希望进行单元测试。我们将使用 Visual Studio 2008、C# 和 ASP.NET MVC 的东西。我正在考虑使用 NUnit 或 Visual Studio 2008 的内置测试项目,但我愿意研究其他建议。一个系统是否比另一个系统更好,或者可能比另一个系统更易于使用/理解?
我希望将这个项目设置为我们未来开发工作的“最佳实践”。
我将在工作中启动一个新项目,并希望进行单元测试。我们将使用 Visual Studio 2008、C# 和 ASP.NET MVC 的东西。我正在考虑使用 NUnit 或 Visual Studio 2008 的内置测试项目,但我愿意研究其他建议。一个系统是否比另一个系统更好,或者可能比另一个系统更易于使用/理解?
我希望将这个项目设置为我们未来开发工作的“最佳实践”。
Daok named all the pro's of Visual Studio 2008 test projects. Here are the pro's of NUnit.
单元测试框架实际上并不重要,因为您可以使用单独的项目文件和条件编译来转换测试类(例如,Visual Studio → NUnit):
#if !NUNIT 使用 Microsoft.VisualStudio.TestTools.UnitTesting; #别的 使用 NUnit.Framework; 使用 TestClass = NUnit.Framework.TestFixtureAttribute; 使用 TestMethod = NUnit.Framework.TestAttribute; 使用 TestInitialize = NUnit.Framework.SetUpAttribute; 使用 TestCleanup = NUnit.Framework.TearDownAttribute; 使用 TestContext = System.String; 使用 DeploymentItem = NUnit.Framework.DescriptionAttribute; #万一
TestDriven.Net 插件很好,而且不是很贵...只有普通的 Visual Studio 2008,您必须从您的测试类或测试列表中找到测试。使用TestDriven.Net,您可以直接从您正在测试的类中运行您的测试。毕竟,单元测试应该易于维护并且靠近开发人员。
Visual Studio 2008 内置单元测试框架的优点/变化:
我已经使用 NUnit 两年了。一切都很好,但我不得不说 Visual Studio 中的单元测试系统非常好,因为它在 GUI 内部,可以更轻松地对私有函数进行测试,而不必乱来。
此外,Visual Studio 的单元测试可以让你做覆盖和其他 NUnit 无法做的事情。
Visual Studio 的测试框架的一个小烦恼是它会创建许多测试运行文件,这些文件往往会使您的项目目录变得混乱——尽管这没什么大不了的。
此外,如果您缺少诸如TestDriven.NET之类的插件,则无法在 Visual Studio 环境中调试 NUnit(或 MbUnit、xUnit 等)单元测试,就像使用内置的 Microsoft Visual Studio 测试框架一样.
有点离题,但如果你使用 NUnit,我可以推荐使用ReSharper——它向 Visual Studio UI 添加了一些按钮,这使得在 IDE 中运行和调试测试变得更加容易。
这篇评论有点过时了,但更详细地解释了这一点:
xUnit是新建项目的另一种可能性。它可能有一种更直观的语法,但它与其他框架并不真正兼容。
我对 NUnit 上的 Visual Studio 单元测试的主要不满是 Visual Studio 测试创建倾向于注入一堆生成的代码以供私有成员访问。
有些人可能想测试他们的私有方法,有些人可能不想。那是一个不同的话题。
我担心的是,当我编写单元测试时,它们应该受到严格控制,这样我才能确切地知道我在测试什么以及我是如何测试它的。如果有自动生成的代码,我将失去一些所有权。
我已经使用这两种方法做了一些TDD,而且(也许我有点笨)NUnit 对我来说似乎更快更简单。当我说很多时,我的意思是很多。
在 MSTest 中,到处都有太多的属性 - 进行真正测试的代码是您可能在这里和那里阅读的那几行代码。一个大乱子。在 NUnit 中,执行测试的代码只是支配属性,这是它应该做的。
此外,在 NUnit 中,您只需单击要运行的测试(只有一个?涵盖一个类的所有测试?一个程序集?解决方案?)。一键点击。窗户又大又干净。你会得到清晰的绿灯和红灯。你真的知道一见钟情。
在VSTS中,测试列表卡在屏幕底部,又小又丑。你必须看两次才能知道发生了什么。而且您不能只运行一项测试(好吧,我还没有发现!)。
但我当然可能是错的——我刚刚阅读了大约 21 篇关于“如何使用 VSTS 进行简单的 TDD”的博客文章。我应该阅读更多;你说的对。
对于 NUnit,我读过一个。我在同一天进行 TDD。带着乐趣。
顺便说一句,我通常喜欢微软的产品。Visual Studio 确实是开发人员可以买到的最好的工具——但是 Visual Studio Team System 中的 TDD 和工作项管理确实很糟糕。
我收到“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
或任何其他转换... :-) 这里的使用只是编译器的别名。
首先,我想纠正一个错误的说法:您可以使用命令行在 Visual Studio 之外运行 MSTest。尽管几个 CI 工具,例如TeamCity,对 NUnit 有更好的支持(可能会随着 MSTest 变得更流行而改变)。
在我当前的项目中,我们同时使用了两者,唯一的区别是我们发现 MSTest 始终以 32 位运行,而 NUnit 以 32 位或 64 位测试运行,这仅在您的代码使用依赖于 32/64 位的本机代码时才重要。
我从 MSTest 开始,但出于一个简单的原因我切换了。MSTest 不支持从其他程序集继承测试方法。
我讨厌多次编写同一个测试的想法。特别是在一个测试方法很容易运行到 100 次测试的大型项目中。
NUnit 正是我所需要的。NUnit 唯一缺少的是一个 Visual Studio 插件,它可以显示每个测试的红色/绿色状态(如VSTS)。
如果您正在考虑 MSTest 或 NUnit,那么我建议您查看MbUnit。我的理由是
using
s。我最初选择 MbUnit 是因为它的 [RowTest ....] 功能,但我还没有找到一个回头的理由。我把我所有的活动测试套件都从 NUnit 转移了过来,并且再也没有回头。从那时起,我已经将两个不同的开发团队转换为收益。
我不喜欢 Visual Studio 的内置测试框架,因为它迫使您创建一个单独的项目,而不是将您的测试作为您正在测试的项目的一部分。
MSTest 本质上是对 NUnit 进行了轻微改造,具有一些新功能(例如装配设置和拆卸,而不仅仅是夹具和测试级别),并且缺少一些最好的位(例如新的 2.4 约束语法)。NUnit 比较成熟,其他厂商的支持也比较多;当然,因为它一直是免费的(而MSTest只进入了 Visual Studio 2008 的专业版,在此之前它的 SKU 价格更高),并且大多数 ALT.NET 项目都使用它。
话虽如此,有些公司非常不愿意使用没有微软标签的东西,尤其是OSS代码。因此,拥有一个官方的微软测试框架可能是这些公司需要进行测试的动机;老实说,重要的是测试,而不是您使用的工具(使用Tuomas Hietanen 的代码,您几乎可以使您的测试框架可互换)。
随着代码合同系统在 .NET 4.0 中的发布和静态检查器的可用性,理论上您将需要编写更少的测试用例,而Pex之类的工具将有助于识别这些用例。将此与手头的讨论联系起来,如果您需要减少单元测试,因为您的合同覆盖了您的尾巴,那么为什么不继续使用内置部件,因为这样可以减少管理依赖项。这些天来,我都是关于简单的。:-)
也可以看看:
我更喜欢使用 MS 的小测试框架,但现在我坚持使用 NUnit。MS的问题通常是(对我来说)
注意事项
我发现编写我的测试并启动 NUnitGUI 或其他前端之一要容易得多(testDriven 的价格远远高出很多)。使用命令行版本设置调试也很容易。