关于c＃：NUnit vs Visual Studio 2008的单元测试测试项目？


NUnit vs Visual Studio 2008's Test Projects for Unit Testing?

我将在工作中启动一个新项目，并希望进入单元测试。我们将使用VS 2008、C_和ASP.NET MVC工具。我正在考虑使用Nunit或VS2008的内置测试项目，但我愿意研究其他建议。一个系统比另一个更好，或者可能比另一个更容易使用/理解吗？我希望这个项目能成为我们未来发展努力的"最佳实践"。

感谢您的帮助和建议！！

daok把VS2008测试项目的所有pro命名为nunit的pro。

  • 努尼特有一个嘲弄的框架。
  • 努尼特可以跑出去IDE，如果你想的话，这很有用在非MS Build服务器上运行测试像cc.net
  • 努尼特有更多版本而不是Visual Studio。你没有等了几年才有新版本您不必安装新版本的IDE获取新功能。
  • 正在开发扩展如排练等。
  • Visual Studio测试需要很长时间为了某种原因启动。这是2008年更好，但还是太慢了为了我的口味。快速运行测试看看你有没有弄坏什么东西可能需要太长时间。努尼特与有点像要运行的TestDriven.net实际上，来自IDE的测试非常多更快。尤其是跑步时单个测试。根据Kjetil Klaussen的说法，这是由Visual Studio TestRunner引起的，在testDriven.net中运行mstest测试可以使mstest的性能与nunit相当。
相关讨论

单元测试框架实际上并不重要，因为您可以使用单独的项目文件和条件编译来转换测试类。(像这样，vs->nunit)：

1
2
3
4
5
6
7
8
9
10
11
 #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

测试驱动的.NET插件很好，而且不是很贵…只有纯VS2008，您必须从测试类或测试列表中找到测试。使用TestDriven.NET，您可以直接从正在测试的类中运行测试。毕竟，单元测试应该易于维护，并且靠近开发人员。

相关讨论

VS2008内置单元测试框架的好处/变化

  • 2008版现在可在专业版(之前需要昂贵的版本，这是给开发单位的测试)留下了很多只有选择开放/外部测试框架。
  • 单一公司支持的内置API。
  • 使用相同的工具运行和创建测试(也可以使用命令行mstest运行它们)
  • 简单设计(不允许使用模拟框架，但对于许多程序员来说，这是一个很好的起点)
  • 长期支持(我仍然记得ndoc发生了什么，我不想承诺5年内可能不支持的测试框架，但我仍然认为nunit是一个很好的框架。)
  • 如果使用Team Foundation Server作为后端，您可以以简单的方式创建失败的测试数据的工作项或缺陷。
    • 相关讨论

    我用努尼特已经两年了。一切都很好，但我不得不说，在VS中的单元系统非常好，因为它在GUI中，可以更容易地进行私有功能的测试，而不必乱来。而且，Vs的单元测试让你可以做覆盖和其他Nunit不能做的事情。

    相关讨论

    Visual Studio的测试框架有一点烦人，那就是它将创建许多测试运行文件，这些文件往往会使项目目录混乱——尽管这不是什么大问题。

    此外，如果缺少诸如testsdriven.net之类的插件，则无法在Visual Studio环境中调试nunit(或mbunit、xunit等)单元测试，就像使用内置的Microsoft vs测试框架一样。

    相关讨论

    稍微偏离主题，但是如果你使用nunit，我可以推荐使用resharper——它在vs用户界面上添加了一些按钮，使得在IDE中运行和调试测试更加容易。

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

    http://codebetter.com/blogs/paul.laudeman/archive/2006/08/15/using-resharper-as-an-essential-part-of-your-tdd-toolkit.aspx

    相关讨论

    我对nunit上的vs单元测试的主要观点是vs测试创建倾向于为私有成员访问注入一组生成的代码。

    有些人可能想测试他们的私有方法，有些人可能不想，这是一个不同的主题。

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

    我已经做了一些TDD同时使用和(也许我有点笨)尼特似乎是一个更快和更简单的使用我。当我说很多的时候，我的意思是很多。

    在MS测试中，到处都有太多的属性——进行真正测试的代码就是您可能在这里或那里读到的微小的行。一团糟。在nunit中，进行测试的代码只是控制属性，正如它应该做的那样。

    此外，在Nunit中，您只需单击要运行的测试(只有一个？所有的考试都包括一门课？集会？解决方案？)。单击。窗户又大又净。你会得到清晰的绿灯和红灯。你真的知道一眼就会发生什么。

    在VSTS中，测试列表被卡在屏幕的底部，它又小又丑。你得看两遍才能知道发生了什么事。你不能只运行一个测试(好吧，我还没有发现！).

    但我可能错了，当然-我刚刚读了21篇关于"如何使用VST做简单的TDD"的博客文章。我应该多读点，你说得对。

    对于努尼特，我读了一本。那天我在打电话。玩得开心。

    顺便说一下，我通常喜欢微软的产品。Visual Studio确实是开发人员可以购买的最佳工具，但在Visual Studio团队系统中，TDD和工作项管理真的很差劲。

    一切顺利。西尔文。

    Xunit是绿地项目的另一种可能性。它可能有一个更直观的语法，但并不真正与其他框架兼容。

    http://www.codeplex.com/xunit

    我收到消息说"nunit文件结构比vstest更丰富"…当然，如果您更喜欢nunit文件结构，您可以使用此解决方案来实现另一种方式，如(nunit->vs)：

    1
    2
    3
    4
    5
    6
    7
    8
    9
     #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。尽管TeamCity等多个CI工具对Nunit有更好的支持(可能会随着MSTest越来越流行而改变)。在我当前的项目中，我们同时使用这两种方法，并且我们发现唯一的区别是，MSTEST总是以32位运行，而nunit是以32位或64位运行，这仅在您的代码使用32/64依赖的本机代码时才重要。

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

    我讨厌多次写同一个测试的想法。尤其是在一个大型项目中，测试方法很容易进行100次测试。

    努尼特确实是我所需要的。nunit唯一缺少的是一个Visual Studio加载项，它可以显示每个测试的红/绿状态(如vsts)。

    如果您考虑的是MSTEST或NUnit，那么我建议您查看MBUnit。我的理由是

  • 测试驱动.NET兼容性。没有任何节拍将testsdriven.net.rerunwithdebugger绑定到键盘组合。
  • 加利奥框架。加利奥是一个像努尼特一样的试车员。唯一的区别是它不关心您是否在nunit、mstest、xunit或mbunit中编写测试。他们都跑了。
  • 与nunit兼容。Nunit中的所有功能都由MBUnit支持。我认为你甚至不需要改变你的属性(需要检查)，只需要你的参考和使用。
  • 集合断言。MBUnit有更多的断言案例，包括CollectionAssert类。基本上，您不再需要编写自己的测试来查看两个集合是否相同。
  • 组合测试。如果你能提供两组数据并对所有的数据组合进行测试，这不是很酷吗？单位为兆字节。

    • 我最初选择MBUnit是因为它的[行测试…]功能，我没有找到返回的单一原因。我把所有活跃的测试套件都从努尼特搬过来，再也没有回头看。从那时起，我已经将两个不同的开发团队转化为利益。

    .NET测试框架建议和.NET单元测试包？.

    相关讨论

    据我所知，目前有四个框架可用于.NET的单元测试

    • 单元测试
    • 多单元
    • 麦斯特
    • 单元测试

    努尼特一直在前面，但差距在过去一年左右已经缩小。我自己还是更喜欢nunit，特别是在不久前他们添加了一个流畅的接口，这使得测试非常可读。

    如果您刚开始进行单元测试，可能不会有什么不同。一旦你达到速度，你将处于一个更好的位置来判断哪个框架最适合你的需要。

    我不喜欢vs内置测试框架，因为它强制您创建一个单独的项目，而不是将测试作为您正在测试的项目的一部分。

    相关讨论

    MSTEST本质上是nunit的轻微修改，具有一些新特性(如装配设置和拆卸，而不仅仅是夹具和测试级别)，并且缺少一些最佳位(如新的2.4约束语法)。Nunit更成熟，其他供应商对它的支持也更多；当然，因为它一直都是免费的(而MSTEST只将它变成了2008年的专业版，在此之前它是更昂贵的sku)，大多数alt.net项目都使用它。

    尽管如此，还是有一些公司非常不愿意使用没有微软标签的东西，特别是OSS代码。因此，拥有一个正式的MS测试框架可能是那些公司需要进行测试的动机；老实说，测试才是最重要的，而不是你使用的工具(并且使用上面的Tuomas Hietanen代码，你几乎可以使你的测试框架可互换)。

    相关讨论

    随着.NET 4.0中代码契约系统的发布和静态检查器的可用性，理论上您需要编写更少的测试用例，并且像pex这样的工具将帮助识别这些用例。把这和手头的讨论联系起来，如果你需要在单元测试上做的更少，因为你的契约覆盖了你的尾部，那么为什么不继续使用内置的部分，因为这是一个更少的管理依赖。这些天，我的一切都是简单的。-)

    另请参见：

    • Microsoft PEX–自动单元测试
    • 使用Visual Studio 2010和C 4.0使用Pex生成单元测试

    我更喜欢使用微软的小型测试框架，但目前仍坚持使用Nunit。MS的问题通常是(对我而言)

    • 必须维护的共享"测试"文件(无意义)
    • 测试列表导致与多个开发人员/VCS发生冲突
    • 集成界面不好-设置混乱，测试选择繁重
    • 没有好的外流道

    注意事项-如果我测试一个ASPX站点，我肯定会使用MS的-如果我是单飞的话，女士也可以-如果我的技能有限，无法配置nunit:)

    我发现只编写测试并启动nunitgui或其他前端(testdriven的定价要高得多)要容易得多。使用命令行版本设置调试也很容易。

    相关讨论