ASP.NET MVC 中的单元测试

发布于 2024-11-05 10:39:32 字数 525 浏览 1 评论 0原文

刚刚开始使用测试框架来编写单元测试以及 TDD 方法。尽管 NUnit 是最好的选择,但没有任何经验,我认为选择 XUnit 会更好。尝试将我在 MVC 书籍中查看的 MS 单元测试方法转换为 XUnit 等效方法,但我已经遇到了困难。

具体如下: 测试视图集合(如索引)的条目列表:

CollectionAssert.AllItemsAreInstancesOfType((ICollection)result.ViewData.Model,typeof(MyObject));  (from MVC unleashed book)

您将如何在 XUnit 中执行此操作,或者不能像这样完成?

让我失望的是 XUnit 缺乏文档,我想知道 NUnit 是否是更好的选择......

而且,测试代码似乎几乎是它自己的语言。可以公平地说,有一组可以针对所有项目运行的通用测试吗?

关于 TDD..我理解这个概念,但是测试本身与单元测试相同,因为它们包含和正在测试的内容?不确定它们被写入时的实际区别是什么!

Just embarking on using a test framework for writing unit tests and also the TDD approach. Not having any prior experience felt it would be good to go for XUnit although NUnit was the best alternative. Trying to transpose the MS Unit testing methods that I have been looking at in the MVC books I have, to XUnit equivalents and am already stumbling.

Specifically the following:
Testing list of entries for a view collection like Index:

CollectionAssert.AllItemsAreInstancesOfType((ICollection)result.ViewData.Model,typeof(MyObject));  (from MVC unleashed book)

How would you do this in XUnit or can't it be done like this?

What puts me off is the lack of documentation for XUnit and am wondering if NUnit is better option.........

Also it appears that the testing code is almost its own language. Would it be fair to say that there is a common set of tests that can be run for all projects?

Regards to TDD..I understand the concept but are the tests themselves the same as unit tests in what they contain and are testing? Not sure what the actual difference is apart from when they get written!

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

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

发布评论

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

评论(3

还不是爱你 2024-11-12 10:39:32

我是 mspec 的粉丝。请参阅这些问题

有用的链接:

MSpec 安装程序

它运行在NUnit 之上。还有 mvc 扩展方法 用于诸如

result.ShouldBeAView().and().ShouldHaveModelOfType<T>()

控制器测试之类的事情

[Subject(typeof(JobsController))]
public class when_viewing_imdex_page : specifications_for_jobs_controller
{
    static ActionResult result;

    Establish context = 
        () => result = controller.Index();

    It should_return_a_view_result = 
        () => result.ShouldBeAView();

    It should_return_a_view_with_formviewdata = 
        () => result.ShouldBeAView().And().ShouldHaveModelOfType<IList<Job>>();

    It should_contain_a_list_of_jobs = 
        () => result.Model<IList<Job>>().ShouldNotBeEmpty();
}

I am a fan of mspec. See these questions

Helpful links :

MSpec installer

It runs on top of NUnit. There are also mvc extension methods for things like

result.ShouldBeAView().and().ShouldHaveModelOfType<T>()

A controller test can look like this

[Subject(typeof(JobsController))]
public class when_viewing_imdex_page : specifications_for_jobs_controller
{
    static ActionResult result;

    Establish context = 
        () => result = controller.Index();

    It should_return_a_view_result = 
        () => result.ShouldBeAView();

    It should_return_a_view_with_formviewdata = 
        () => result.ShouldBeAView().And().ShouldHaveModelOfType<IList<Job>>();

    It should_contain_a_list_of_jobs = 
        () => result.Model<IList<Job>>().ShouldNotBeEmpty();
}
玩物 2024-11-12 10:39:32

我不了解 XUnit,但在 NUnit 中存在集合约束
看看这个 NUnit

作为你的例子,你可以使用这个代码

Assert.That((ICollection)result.ViewData.Model, Is.All.InstanceOf<MyObject>());

I don't know about XUnit but in NUnit there is collections constraints
look at this NUnit

for your example you could use this code

Assert.That((ICollection)result.ViewData.Model, Is.All.InstanceOf<MyObject>());
哆兒滾 2024-11-12 10:39:32

我认为对我来说评论你应该使用哪个测试框架是不公平的,因为我只使用过 NUnit,但它对我来说已经足够了。

然而,关于你的第二点和第三点;大多数测试都非常相似,但这就是 TDD 的要点,从基础开始,继续重构,直到“不多也不少”。

测试驱动开发和开发后测试都是单元测试的一种形式;但在 TDD 中,测试正在推动开发,确保您编写的每一行都有其目的并且经过充分测试。

有缺点;有时,您必须在测试之前编写代码(尤其是在开始时),这样您就可以弄清楚如何测试它,因此可以公平地说您的开发将包含上述两种类型。

TDD 和任何形式的自动化测试绝对值得付出努力,即使只是为了在最终测试运行中看到应用程序中通过数百个测试而获得的满足感。

I think it would be unfair for me to comment on which Testing Framework you should use, having only used NUnit, but it's always been enough for me.

Regarding your second and third points however; the majority of tests a very similar, but that is the point of TDD, start from the base, and continue refactoring until you have "no more, and no less".

Test Driven Development and Test After Development are both a form of Unit Testing; but within TDD, the tests are DRIVING the development, ensuring that every line you write has a purpose and is fully tested.

There are disadvantages; sometimes, you have to write the code before testing (especially when starting out), so you can figure out how to test it, so it may be fair to say that your development will contain a bit of both types mentioned.

TDD, and any form of automated testing is definitely worth the effort, if for nothing but the satisfaction you get from seeing hundreds of tests pass in your application on your final test run.

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