255

我将在工作中启动一个新项目,并希望进行单元测试。我们将使用 Visual Studio 2008、C# 和 ASP.NET MVC 的东西。我正在考虑使用 NUnit 或 Visual Studio 2008 的内置测试项目,但我愿意研究其他建议。一个系统是否比另一个系统更好,或者可能比另一个系统更易于使用/理解?

我希望将这个项目设置为我们未来开发工作的“最佳实践”。

4

18 回答 18

99

Daok named all the pro's of Visual Studio 2008 test projects. Here are the pro's of 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.
于 2008-09-18T14:33:41.713 回答
64

单元测试框架实际上并不重要,因为您可以使用单独的项目文件和条件编译来转换测试类(例如,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,您可以直接从您正在测试的类中运行您的测试。毕竟,单元测试应该易于维护并且靠近开发人员。

于 2008-09-18T14:59:22.447 回答
34

Visual Studio 2008 内置单元测试框架的优点/变化:

  1. 2008 版现在有专业版(之前它需要昂贵的 Visual Studio 版本,这仅用于开发人员单元测试),这让许多开发人员只能选择开放/外部测试框架。
  2. 单一公司支持的内置 API。
  3. 使用相同的工具来运行和创建测试(您也可以使用命令行运行它们MSTest)。
  4. 简单的设计(在没有模拟框架的情况下被授予,但这对许多程序员来说是一个很好的起点)。
  5. 授予长期支持(我仍然记得NDoc发生了什么,我不想承诺五年内可能不会支持的测试框架,但我仍然认为 NUnit 是一个很棒的框架)。
  6. 如果使用 Team Foundation Server 作为后端,您可以使用失败的测试数据以简单的方式创建工作项或错误。
于 2008-11-18T16:49:28.723 回答
33

我已经使用 NUnit 两年了。一切都很好,但我不得不说 Visual Studio 中的单元测试系统非常好,因为它在 GUI 内部,可以更轻松地对私有函数进行测试,而不必乱来。

此外,Visual Studio 的单元测试可以让你做覆盖和其他 NUnit 无法做的事情。

于 2008-09-18T14:13:30.530 回答
14

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

此外,如果您缺少诸如TestDriven.NET之类的插件,则无法在 Visual Studio 环境中调试 NUnit(或 MbUnit、xUnit 等)单元测试,就像使用内置的 Microsoft Visual Studio 测试框架一样.

于 2008-09-19T22:35:35.517 回答
14

有点离题,但如果你使用 NUnit,我可以推荐使用ReSharper——它向 Visual Studio UI 添加了一些按钮,这使得在 IDE 中运行和调试测试变得更加容易。

这篇评论有点过时了,但更详细地解释了这一点:

将 ReSharper 用作 TDD 工具包的重要组成部分

于 2008-11-28T11:28:50.987 回答
11

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

于 2008-09-18T19:46:57.437 回答
11

我对 NUnit 上的 Visual Studio 单元测试的主要不满是 Visual Studio 测试创建倾向于注入一堆生成的代码以供私有成员访问。

有些人可能想测试他们的私有方法,有些人可能不想。那是一个不同的话题。

我担心的是,当我编写单元测试时,它们应该受到严格控制,这样我才能确切地知道我在测试什么以及我是如何测试它的。如果有自动生成的代码,我将失去一些所有权。

于 2009-03-08T06:59:28.747 回答
11

我已经使用这两种方法做了一些TDD,而且(也许我有点笨)NUnit 对我来说似乎更快更简单。当我说很多时,我的意思是很多。

在 MSTest 中,到处都有太多的属性 - 进行真正测试的代码是您可能在这里和那里阅读的那几行代码。一个大乱子。在 NUnit 中,执行测试的代码只是支配属性,这是它应该做的。

此外,在 NUnit 中,您只需单击要运行的测试(只有一个?涵盖一个类的所有测试?一个程序集?解决方案?)。一键点击。窗户又大又干净。你会得到清晰的绿灯和红灯。你真的知道一见钟情。

在VSTS中,测试列表卡在屏幕底部,又小又丑。你必须看两次才能知道发生了什么。而且您不能只运行一项测试(好吧,我还没有发现!)。

但我当然可能是错的——我刚刚阅读了大约 21 篇关于“如何使用 VSTS 进行简单的 TDD”的博客文章。我应该阅读更多;你说的对。

对于 NUnit,我读过一个。我在同一天进行 TDD。带着乐趣。

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

于 2009-07-08T20:46:26.213 回答
9

我收到“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

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

于 2009-02-13T18:53:46.640 回答
9

首先,我想纠正一个错误的说法:您可以使用命令行在 Visual Studio 之外运行 MSTest。尽管几个 CI 工具,例如TeamCity,对 NUnit 有更好的支持(可能会随着 MSTest 变得更流行而改变)。

在我当前的项目中,我们同时使用了两者,唯一的区别是我们发现 MSTest 始终以 32 位运行,而 NUnit 以 32 位或 64 位测试运行,这仅在您的代码使用依赖于 32/64 位的本机代码时才重要。

于 2008-09-19T20:25:49.103 回答
8

我从 MSTest 开始,但出于一个简单的原因我切换了。MSTest 不支持从其他程序集继承测试方法。

我讨厌多次编写同一个测试的想法。特别是在一个测试方法很容易运行到 100 次测试的大型项目中。

NUnit 正是我所需要的。NUnit 唯一缺少的是一个 Visual Studio 插件,它可以显示每个测试的红色/绿色状态(如VSTS)。

于 2009-06-12T05:53:22.007 回答
7

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

  1. TestDriven.Net 兼容性。没有什么比 TestDriven.Net.ReRunWithDebugger 绑定到键盘组合更好了。
  2. 加里奥框架。Gallio 是像 NUnit 一样的测试运行器。唯一的区别是它不在乎你是用 NUnit、MSTestxUnit还是 MbUnit 编写测试。他们都跑了。
  3. 与 NUnit 的兼容性。MbUnit 支持 NUnit 中的所有功能。我认为您甚至不需要更改您的属性(必须检查),只需您的参考和usings。
  4. 集合断言。MbUnit 有更多的 Assert 案例,包括 CollectionAssert 类。基本上,您不再需要编写自己的测试来查看两个集合是否相同。
  5. 组合测试。如果您可以提供两组数据并针对所有数据组合进行测试,那不是很酷吗?它以 MbUnit 为单位。

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

于 2009-08-23T22:40:30.027 回答
6

据我所知,目前有四个框架可用于使用 .NET 进行单元测试:

NUnit 一直处于领先地位,但在过去一年左右的时间里,差距已经缩小。我自己还是更喜欢 NUnit,尤其是他们不久前添加了一个流畅的界面,这使得测试非常易读。

如果您刚刚开始进行单元测试,它可能不会有太大的不同。一旦您掌握了速度,您将能够更好地判断哪种框架最适合您的需求。

于 2008-09-19T20:52:18.667 回答
6

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

于 2010-04-21T14:17:54.557 回答
5

MSTest 本质上是对 NUnit 进行了轻微改造,具有一些新功能(例如装配设置和拆卸,而不仅仅是夹具和测试级别),并且缺少一些最好的位(例如新的 2.4 约束语法)。NUnit 比较成熟,其他厂商的支持也比较多;当然,因为它一直是免费的(而MSTest只进入了 Visual Studio 2008 的专业版,在此之前它的 SKU 价格更高),并且大多数 ALT.NET 项目都使用它。

话虽如此,有些公司非常不愿意使用没有微软标签的东西,尤其是OSS代码。因此,拥有一个官方的微软测试框架可能是这些公司需要进行测试的动机;老实说,重要的是测试,而不是您使用的工具(使用Tuomas Hietanen 的代码,您几乎可以使您的测试框架可互换)。

于 2009-01-14T03:23:47.520 回答
4

随着代码合同系统在 .NET 4.0 中的发布和静态检查器的可用性,理论上您将需要编写更少的测试用例,而Pex之类的工具将有助于识别这些用例。将此与手头的讨论联系起来,如果您需要减少单元测试,因为您的合同覆盖了您的尾巴,那么为什么不继续使用内置部件,因为这样可以减少管理依赖项。这些天来,我都是关于简单的。:-)

也可以看看:

于 2010-11-09T02:35:54.677 回答
3

我更喜欢使用 MS 的小测试框架,但现在我坚持使用 NUnit。MS的问题通常是(对我来说)

  • 必须维护的共享“测试”文件(无意义)
  • 测试列表会导致与多个开发人员/VCS 发生冲突
  • 糟糕的集成 UI - 混乱的设置,繁琐的测试选择
  • 没有好的外部跑步者

注意事项

  • 如果我正在测试一个 aspx 站点,我肯定会使用 MS 的
  • 如果我是单独开发,MS也可以
  • 如果我的技能有限并且无法配置 NUnit :)

我发现编写我的测试并启动 NUnitGUI 或其他前端之一要容易得多(testDriven 的价格远远高出很多)。使用命令行版本设置调试也很容易。

于 2009-05-22T20:54:24.253 回答