一个单元应该如何测试.NET MVC控制器?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (15)

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

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

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

任何人都可以提出一些更好的方法来控制器单元测试或解释为什么上述方法是有效/有用的?

提问于
用户回答回答于

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

你编写单元测试来在非常特定的场景/情况下以非常特定的方式声明控制器的行为。数据层是向控制器/操作方法提供这些情况的应用程序的一部分。断言由控制器调用的服务方法非常有用,因为可以确定控制器从另一个位置获取信息。

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

单元测试可以是有价值的,因为它们使重构变得更容易。可以更改实现,并确保所有单元测试都通过,但行为仍然相同。

如果更改被测方法的实现需要更改/删除较低层的模拟方法,那么单元测试也必须更改。但是,这不应该像你想象的那样频繁发生。

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

如果你先编写单元测试,你会发现控制器需要从低层获取信息。你怎么能确定它试图获得这些信息?通过嘲笑提供信息的低层方法,并断言控制器调用低层方法。

当我使用“更改实施”这个术语时,我可能会错过。当控制器的操作方法和相应的单元测试必须改变以改变或移除模拟方法时,您确实正在改变控制器的行为。根据定义,重构意味着改变实现而不改变整体行为和预期结果。

红绿重构是一种质量保证方法,有助于防止代码出现之前的错误和缺陷。通常情况下,开发人员会改变实施方式,以便在出现错误后将其删除 因此,重申一下,担心的事件不应该像想象的那样频繁发生。

用户回答回答于

你应该首先让你的控制器节食。然后你可以单元测试它们。如果他们很胖,而且你已经把所有的业务逻辑塞进了他们的内部,我同意你会在你的单元测试中mock你的生活,并抱怨说这是浪费时间。

当你谈论复杂的逻辑时,这并不一定意味着这个逻辑不能在不同的层中分开,每个方法都要单独进行单元测试。

扫码关注云+社区