一个单元应该如何测试 .NET MVC 控制器? [英] How should one unit test a .NET MVC controller?

问题描述

我正在寻找有关 .NET mvc 控制器的有效单元测试的建议.

I'm looking for advice regarding effective unit testing of .NET mvc controllers.

在我工作的地方，许多这样的测试使用 moq 来模拟数据层并断言某些数据层方法被调用.这对我来说似乎没什么用，因为它本质上是验证实现没有改变，而不是测试 API.

Where I work, many such tests use moq to mock the data layer and to assert that certain data-layer methods are called. This doesn't seem useful to me, since it essentially verifies that the implementation has not changed rather than testing the API.

我也读过一些文章推荐诸如检查返回的视图模型类型是否正确.我可以看到它提供了一些价值，但仅凭它似乎并不值得编写多行模拟代码(我们应用程序的数据模型非常庞大和复杂).

I've also read articles recommending things like checking that the type of view model returned is correct. I can see that providing some value, but alone it doesn't seem to merit the effort of writing many lines of mocking code (our application's data model is very large and complex).

谁能建议一些更好的控制器单元测试方法或解释为什么上述方法有效/有用?

Can anyone suggest some better approaches to controller unit testing or explain why the above approaches are valid/useful?

谢谢！

推荐答案

控制器单元测试应该在您的操作方法中测试代码算法，而不是在您的数据层中.这是模拟这些数据服务的原因之一.控制器期望从存储库/服务/等接收某些值，并在从它们接收到不同的信息时采取不同的行动.

A controller unit test should test the code algorithms in your action methods, not in your data layer. This is one reason to mock those data services. The controller expects to receive certain values from repositories / services / etc, and to act differently when it receives different information from them.

您编写单元测试来断言控制器在非常特定的场景/情况下以非常特定的方式运行.您的数据层是为控制器/操作方法提供这些情况的应用程序的一部分.断言服务方法被控制器调用是有价值的，因为您可以确定控制器从另一个地方获取信息.

You write unit tests to assert the controller behaves in very specific ways in very specific scenarios / circumstances. Your data layer is one piece of the app that provides those circumstances to the controller / action methods. Asserting that a service method was called by the controller is valuable because you can be certain that the controller gets the information from another place.

检查返回的视图模型的类型是有价值的，因为如果返回错误的视图模型类型，MVC 将抛出运行时异常.您可以通过运行单元测试来防止这种情况在生产中发生.如果测试失败，那么视图可能会在生产中抛出异常.

Checking the type of the viewmodel returned is valuable because, if the wrong type of viewmodel is returned, MVC will throw a runtime exception. You can prevent this from happening in production by running a unit test. If the test fails, then the view may throw an exception in production.

单元测试很有价值，因为它们使重构变得更加容易.您可以更改实现，并通过确保所有单元测试通过来断言行为仍然相同.

Unit tests can be valuable because they make refactoring much easier. You can change the implementation, and assert that the behavior is still the same by making sure all of the unit tests pass.

回复评论 #1

如果更改被测方法的实现需要更改/删除下层模拟方法，那么单元测试也必须更改.但是，这不应该像您想象的那样经常发生.

If changing the implementation of a method-under-test calls for the change / removal of a lower-layer mocked method, then the unit test must also change. However, this shouldn't happen as often as you may think.

典型的红绿重构工作流程要求在编写测试方法之前编写单元测试.(这意味着在很短的时间内，您的测试代码将无法编译，这也是许多年轻/缺乏经验的开发人员难以采用红绿重构的原因.)

The typical red-green-refactor workflow calls for writing your unit tests before writing the methods they test. (This means for a brief amount of time, your test code won't compile, and is why many young / inexperienced developers have difficulty adopting red green refactor.)

如果您首先编写单元测试，您将知道控制器需要从较低层获取信息.您如何确定它会尝试获取该信息?通过模拟提供信息的下层方法，并断言控制器调用了下层方法.

If you write your unit tests first, you will come to a point where you know the controller needs to get information from a lower layer. How can you be certain it tries to get that information? By mocking out the lower layer method that provides the information, and asserting that the lower-layer method is invoked by the controller.

当我使用改变实施"这个词时，我可能说错了.当控制器的动作方法 &必须更改相应的单元测试以更改或删除模拟方法，您实际上是在更改控制器的行为.根据定义，重构意味着在不改变整体行为和预期结果的情况下改变实现.

I may have misspoke when I used the term "changing implementation." When a controller's action method & corresponding unit test must be altered to change or remove a mocked method, you are really changing the behavior of the controller. Refactoring, by definition, means changing the implementation without altering the overall behavior and expected results.

红绿重构是一种质量保证方法，有助于防止错误和在代码缺陷出现之前.通常，开发人员会在错误出现后更改实现以将其删除.所以重申一下，你担心的情况不应该像你想象的那样经常发生.

Red-green-refactor is a Quality Assurance approach that helps prevent bugs & defects in code before they ever appear. Typically developers change implementation to remove bugs after they appear. So to reiterate, the cases you are worried about should not happen as often as you think.

这篇关于一个单元应该如何测试 .NET MVC 控制器?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！