当前位置： 文江博客话题详情

NUnit 与 Visual Studio 2008 的单元测试测试项目

发布于 2024-07-05 18:02:24 字数 207 浏览 7 评论 0原文

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

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

原文

I am going to be starting up a new project at work and want to get into unit testing. We will be using Visual Studio 2008, C#, and the ASP.NET MVC stuff. I am looking at using either NUnit or the built-in test projects that Visual Studio 2008 has, but I am open to researching other suggestions. Is one system better than the other or perhaps easier to use/understand than the other?

I am looking to get this project set up as kind of the "best practice" for our development efforts going forward.

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（18）

ζ澈沫 2024-07-12 18:02:24

我一开始使用的是 MSTest，但出于一个简单的原因我转而使用。 MSTest 不支持从其他程序集继承测试方法。

我讨厌多次编写同一个测试的想法。 特别是在大型项目中，测试方法可以轻松运行数百次测试。

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

I started with MSTest, but I switched for one simple reason. MSTest does not support inheritance of test methods from other assemblies.

I hated the idea of writing the same test multiple times. Especially on a large project where test methods can easily run into 100's of tests.

NUnit does exactly what I need. The only thing that is missing with NUnit is a Visual Studio addin which has can display the red/green status (like VSTS) of each test.

回复 原文
染年凉城似染瑾 2024-07-12 18:02:24

如果您正在考虑 MSTest 或 NUnit，那么我建议您查看 MbUnit。 我的原因是

  1. TestDriven.Net 兼容性。 没有什么比将 TestDriven.Net.ReRunWithDebugger 绑定到键盘组合更好的了。
  2. 加里奥框架。 Gallio 是一个类似于 NUnit 的测试运行器。 唯一的区别是它不关心您是否在 NUnit 中编写测试， MSTest, < a href="https://en.wikipedia.org/wiki/XUnit" rel="nofollow noreferrer">xUnit 或 MbUnit。 他们都跑了。
  3. 与 NUnit 的兼容性。 MbUnit 支持 NUnit 中的所有功能。 我认为您甚至不需要更改您的属性（必须检查），只需更改您的引用和using即可。
  4. 集合断言。 MbUnit 有更多的 Assert 案例，包括 CollectionAssert 类。 基本上，您不再需要编写自己的测试来查看两个集合是否相同。
  5. 组合测试。 如果您可以提供两组数据并对所有数据组合进行测试，这不是很酷吗？ 它以 Mb 为单位。

我最初选择 MbUnit 是因为它的 [RowTest ....] 功能，但我没有找到任何回头的理由。 我将所有活跃的测试套件从 NUnit 转移过来，并且再也没有回头。 从那时起，我已经将两个不同的开发团队转变为受益者。

If you are considering either MSTest or NUnit, then I recommend you look at MbUnit. My reasons are

  1. TestDriven.Net compatibility. Nothing beats have TestDriven.Net.ReRunWithDebugger bound to a keyboard combination.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

I originally picked up MbUnit because of its [RowTest ....] functionality, and I haven't found a single reason to go back. I moved all my active test suites over from NUnit and never looked back. Since then I've converted two different development teams over to the benefits.

回复 原文
人间☆小暴躁 2024-07-12 18:02:24

据我所知，现在有四种可用于 .NET 单元测试的框架：

NUnit 始终一直处于领先地位，但差距在去年左右已经缩小。 我自己仍然更喜欢 NUnit，特别是因为他们不久前添加了一个流畅的界面，这使得测试非常具有可读性。

如果您刚刚开始进行单元测试，那么它可能没有多大区别。 一旦您掌握了最新情况，您将能够更好地判断哪个框架最适合您的需求。

As far as I know, there are four frameworks available for unit testing with .NET these days:

NUnit has always been out in front, but the gap has closed in the last year or so. I still prefer NUnit myself, especially as they added a fluent interface a while back which makes tests very readable.

If you're just getting started with unit testing it probably doesn't make much difference. Once you're up to speed, you'll be in a better position to judge which framework is best for your needs.

回复 原文
七婞 2024-07-12 18:02:24

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

I don't like the Visual Studio's built-in testing framework, because it forces you to create a separate project as opposed to having your tests as part of the project you're testing.

回复 原文
娇纵 2024-07-12 18:02:24

MSTest 本质上是对 NUnit 进行了轻微的修改，具有一些新功能（例如程序集设置和拆卸，而不仅仅是夹具和测试级别），并且缺少一些最好的位（例如新的 2.4 约束语法）。 NUnit更加成熟，并且有更多其他厂商对其的支持； 当然，因为它始终是免费的（而 MSTest 仅进入 Visual 的专业版本Studio 2008，以及在此之前它的 SKU 更昂贵），并且大多数 ALT.NET 项目都使用它。

话虽如此，有些公司非常不愿意使用没有 Microsoft 标签的东西，尤其是 OSS代码。 所以拥有一个微软官方的测试框架可能是那些公司需要进行测试的动力； 老实说，重要的是测试，而不是您使用什么工具（并使用 Tuomas Hietanen 的代码，您几乎可以使您的测试框架互换）。

MSTest is essentially NUnit slightly reworked, with a few new features (such as assembly setup and teardown, not just fixture and test level), and missing some of the best bits (such as the new 2.4 constraint syntax). NUnit is more mature, and there is more support for it from other vendors; and of course since it's always been free (whereas MSTest only made it into the Professional version of Visual Studio 2008, and before that it was in way more expensive SKUs), and most ALT.NET projects use it.

Having said that, there are some companies who are incredibly reluctant to use something which does not have the Microsoft label on it, and especially so OSS code. So having an official Microsoft test framework may be the motivation that those companies need to get testing; and let's be honest, it's the testing that matters, not what tool you use (and using Tuomas Hietanen's code, you can almost make your test framework interchangeable).

回复 原文
百思不得你姐 2024-07-12 18:02:24

随着 .NET 4.0 中代码契约系统的发布以及可用性静态检查器，理论上您需要编写更少的测试用例，并且像 Pex 这样的工具将有助于识别这些情况。 将这一点与当前的讨论联系起来，如果您需要减少单元测试的数量，因为您的合同覆盖了您的尾巴，那么为什么不继续使用内置部分，因为这是一个需要管理的更少的依赖项。 这些天，我崇尚简单。 :-)

另请参阅：

With the release in .NET 4.0 of the Code Contracts system and the availability of a static checker, you would need to theoretically write fewer test cases and a tool like Pex will help identify those cases. Relating this to the discussion at hand, if you need to do less with your unit tests because your contracts are covering your tail, then why not just go ahead and use the built-in pieces since that is one less dependency to manage. These days, I am all about simplicity. :-)

See also:

回复 原文
遗失的美好 2024-07-12 18:02:24

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

  • 必须维护的共享“测试”文件（毫无意义）
  • 测试列表会导致与多个开发人员/VCS 发生冲突
  • 集成 UI 较差 - 设置混乱、测试选择繁重
  • 不好外部运行器

注意事项

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

我找到了它编写我的测试并启动 NUnitGUI 或其他前端之一要容易得多（testDriven 的价格远远过高）。 使用命令行版本设置调试也非常简单。

I would prefer to use MS's little test framework, but for now am sticking with NUnit. The problems with MS's are generally (for me)

  • Shared "tests" file (pointless) that must be maintained
  • Tests lists cause conflicts with multiple developers / VCSs
  • Poor integrated UI - confusing setup, burdensome test selection
  • No good external runner

Caveats

  • If I were testing an aspx site, I would definitely use MS's
  • If I were developing solo, also MS would be fine
  • If I had limited skill and couldn't configure NUnit :)

I find it much easier to just write my tests and fire up NUnitGUI or one of the other front ends (testDriven is far far far far overpriced). Setting up debugging with the commandline version is also pretty easy.

回复 原文
才能让你更想念 2024-07-12 18:02:24

Daok 命名了所有Visual Studio 2008 测试项目的专业版。 以下是 NUnit 的优点。

  • NUnit 有一个模拟框架。
  • NUnit 可以在外部运行
    IDE。 如果您愿意，这会很有用
    在非 Microsoft 构建服务器上运行测试，
    例如 CruiseControl.NET。
  • NUnit 有更多版本即将推出
    比视觉工作室。 你没有
    等待新版本数年。
    而且您不必安装新版本的 IDE 即可
    获得新功能。
  • 有扩展正在开发中
    对于 NUnit，如行测试等。Visual
  • Studio 测试需要很长时间
    由于某种原因启动。 这是
    在 Visual Studio 2008 中更好，
    但还是太慢了
    适合我的口味。 快速运行测试
    看看你是否没有弄坏什么东西
    可能需要很长时间。 NUnit 与
    像 Testdriven.Net 一样运行
    来自IDE的测试实际上很多
    快点。 尤其是跑步的时候
    单一测试。
    根据 Kjetil Klaussen 的说法，这是由 Visual Studio 测试运行程序引起的。 在 TestDriven.Net 中运行 MSTest 测试使 MSTest 性能与 NUnit 相当。

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.
回复 原文
水波映月 2024-07-12 18:02:24

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

The unit-testing framework doesn't actually matter much, because you can convert test classes with separate project files and conditional compilation (like this, 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

The TestDriven.Net plugin is nice and not very expensive... With only plain Visual Studio 2008 you have to find the test from your test class or test list. With TestDriven.Net you can run your test directly from the class that you are testing. After all, unit tests should be easy to maintain and near the developer.

回复 原文
—━☆沉默づ 2024-07-12 18:02:24

Visual Studio 2008 内置单元测试框架的优点/更改：

  1. 2008 版本现在可在
    专业版（之前
    需要昂贵版本的 Visual Studio，并且
    这仅适用于开发单位
    测试）留下了很多
    开发商唯一的选择
    开放/外部测试框架。
  2. 由单一公司支持的内置 API。
  3. 使用相同的工具来运行和创建测试（您也可以使用命令行运行它们 MSTest）。
  4. 简单的设计（无需模拟框架即可实现，但这对于许多程序员来说是一个很好的起点）。
  5. 授予长期支持（我仍然记得 NDoc 发生了什么，而且我不想致力于一个可能在五年内不受支持的测试框架，但我仍然认为 NUnit 是一个很棒的框架）。
  6. 如果使用 Team Foundation Server 作为后端，您可以以简单的方式使用失败的测试数据创建工作项或错误。

Benefits/changes of the Visual Studio 2008 built-in unit testing framework:

  1. The 2008 version now is available in
    professional editions (before it
    required expensive versions of Visual Studio, and
    this is just for developer unit
    testing) that left a lot of
    developers with the only choice of
    open/external testing frameworks.
  2. Built-in API supported by a single company.
  3. Use the same tools to to run and create tests (you may run them using the command line also MSTest).
  4. Simple design (granted without a mock framework, but this is a great starting point for many programmers).
  5. Long term support granted (I still remember what happened to NDoc, and I don't want to commit to a testing framework that might not be supported in five years, but I still consider NUnit a great framework).
  6. If using Team Foundation Server as your backend, you can create work items or bugs with the failed test data in a simple fashion.
回复 原文
甜嗑 2024-07-12 18:02:24

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

此外，Visual Studio 的单元测试可以让您完成覆盖和其他 NUnit 单独无法完成的工作。

I have been using NUnit for two years. All is fine, but I have to say that the unit testing system in Visual Studio is pretty nice, because it's inside the GUI and can more easily do a test for private function without having to mess around.

Also, the unit testing of Visual Studio lets you do covering and other stuff that NUnit alone can't do.

回复 原文
青衫负雪 2024-07-12 18:02:24

Visual Studio 测试框架的一个小问题是，它会创建许多测试运行文件，这些文件往往会弄乱您的项目目录 - 尽管这并不是什么大问题。

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

One slight annoyance of Visual Studio's testing framework is that it will create many test run files that tend to clutter your project directory - though this isn't that big of a deal.

Also, if you lack a plugin such as TestDriven.NET, you cannot debug your NUnit (or MbUnit, xUnit, etc.) unit tests within the Visual Studio environment, as you can with the Microsoft Visual Studio testing framework, which is built in.

回复 原文
生生不灭 2024-07-12 18:02:24

有点偏离主题，但如果您使用 NUnit，我建议您使用 ReSharper - 它添加了一些按钮Visual Studio UI 使在 IDE 中运行和调试测试变得更加容易。

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

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

Slightly off-topic, but if you go with NUnit I can recommend using ReSharper - it adds some buttons to the Visual Studio UI that make it a lot easier to run and debug tests from within the IDE.

This review is slightly out-of-date, but explains this in more detail:

Using ReSharper as an essential part of your TDD toolkit

回复 原文
七度光 2024-07-12 18:02:24

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

xUnit is another possibility for a greenfield project. It's got perhaps a more intuitive syntax, but it is not really compatible with the other frameworks.

回复 原文
傲影 2024-07-12 18:02:24

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

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

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

My main beef with Visual Studio unit tests over NUnit is the Visual Studio test creation tends to inject a bunch of generated code for private member access.

Some might want to test their private methods, and some may not. That's a different topic.

My concern is when I'm writing unit tests they should be extremely controlled so I know exactly what I'm testing and exactly how I'm testing it. If there's auto generated code I'm losing some of that ownership.

回复 原文
青衫儰鉨ミ守葔 2024-07-12 18:02:24

我已经使用 NUnit 和（也许我有点傻）做了一些 TDD对我来说使用起来似乎更快更简单。 当我说很多的时候，我的意思是很多。

在 MSTest 中，到处都有太多的属性 - 执行真正测试的代码是您可能会在这里或那里读到的小行。 一团糟。 在 NUnit 中，执行测试的代码只控制属性，这是它应该做的。

另外，在 NUnit 中，您只需单击要运行的测试（只有一个？涵盖一个类的所有测试？程序集？解决方案？）。 一键点击。 而且窗户又大又清晰。 您会看到清晰的绿灯和红灯。 你真的一眼就知道会发生什么。

在VSTS中，测试列表挤在屏幕底部，而且又小又难看。 你必须看两遍才能知道发生了什么。 而且你不能只运行一项测试（好吧，我还没发现！）。

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

对于 NUnit，我读过一篇。 当天我就在 TDD 中。 充满乐趣。

顺便说一下，我平时很喜欢微软的产品。 Visual Studio 确实是开发人员可以购买的最好工具 - 但 Visual Studio Team System 中的 TDD 和工作项管理确实很糟糕。

I have done some TDD using both and (maybe I'm a little dumb) NUnit seems to be a lot faster and simpler to use to me. And when I say a lot, I mean a lot.

In MSTest, there is too many attributes, everywhere - the code that do the real tests is the tiny lines you may read here and there. A big mess. In NUnit, the code that do the test just dominates the attributes, as it should do.

Also, in NUnit, you just have to click on the tests you want to run (only one? All the tests covering a class? An assembly? The solution?). One click. And the window is clear and large. You get clear green and red lights. You really know what happens in one sight.

In VSTS, the test list is jammed in the bottom of the screen, and it's small and ugly. You have to look twice to know what happened. And you cannot run just one test (well, I did not find out yet!).

But I may be wrong, of course - I just read about 21 blog posts about "How to do simple TDD using VSTS". I should have read more; you are right.

For NUnit, I read one. And I was TDDing the same day. With fun.

By the way, I usually love Microsoft products. Visual Studio is really the best tool a developer can buy - but TDD and Work Item management in Visual Studio Team System sucks, really.

回复 原文
煮茶煮酒煮时光 2024-07-12 18:02:24

首先我想纠正一个错误的说法：您可以使用命令行在 Visual Studio 之外运行 MSTest。 尽管一些 CI 工具，例如 TeamCity，对 NUnit 有更好的支持（可能会随着 MSTest 的变化而改变）变得更受欢迎）。

在我当前的项目中，我们使用两者，我们发现 MSTest 始终作为 32 位运行，而 NUnit 作为 32 位或 64 位测试运行，这仅在您的代码使用依赖于 32/64 位的本机代码时才重要。

First I want to correct a wrong statement: you can run MSTest outside of Visual Studio using the command line. Although several CI tools, such as TeamCity, have better support for NUnit (probably would change as MSTest becomes more popular).

In my current project we use both and the only big difference we found that MSTest always runs as a 32 bit while NUnit runs as either 32 bit or 64 bit tests which only matters if your code uses native code that is 32/64 bit dependent.

回复 原文
美人迟暮 2024-07-12 18:02:24

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

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

I got messages that "NUnit file structure is richer than VSTest"...
Of course, if you prefer the NUnit file structure, you can use this solution to the other way, like this (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

Or any other conversion... :-) This use here is just an alias to the compiler.

回复 原文
~没有更多了~

关于作者

短叹

暂无简介

0 文章
0 评论
23 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

内心激荡

文章 0 评论 0

JSmiles

文章 0 评论 0

赏烟花じ飞满天

文章 0 评论 0

左秋

文章 0 评论 0

迪街小绵羊

文章 0 评论 0

瞳孔里扚悲伤

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文