0

假设您有一个项目，其中有许多开发人员在同一个 Asp.net MVC 应用程序上工作。项目是一个长期的项目，所以团队成员会随着时间而改变。这意味着在这段时间里，我们达到了某些观点似乎（完全）与其他观点不同的地步。标记明智。

为了随着时间的推移保持 UI 尽可能一致，假设最初的团队开发了一种流畅的 Html 辅助方法，用于创建通用视图结构。IE：

Html.CreateHeader("Header text")
    .CreateForm(Url.Action(...))
    .AddSegment("Person")
    .EditorFor(model => model.Person)
    .AddSegment("...")
    .EditorFor(model => model.Company)
    ...

尽管这确实为日常 Asp.net MVC 视图代码添加了额外的抽象，但它使视图随着时间的推移保持一致。当然，当使用这些流利的助手时。

但是。尽管这些辅助方法中的每一个都可以进行单元测试，但我想知道测试视图本身有什么好处？

问题

  1. 我的观点是你不会对任何静态的东西（即视图）进行单元测试。因此，除非视图具有丰富的客户端功能，否则不应测试任何内容。但如果是这样，您将使用 ie 测试 Javascript 代码。QUnit 库。这种想法是否正确，或者测试本质上是静态的东西真的有意义吗？我们只会测试某些元素及其内容的存在吗？

  2. 可以测试视图的哪些其他方面以及为什么要测试它们？

在我的开发过程中，我注意到单元测试应该只对非平凡的代码进行。换句话说，至少有一个分支的方法应该被测试，而其他的方法足够长以至于即使没有分支也不完全清楚他们所做的事情。

我倾向于避免为本质上微不足道的方法编写单元测试，因为它们除了消耗开发人员的时间之外没有任何帮助。

4

1 回答 1

2

视图应该只呈现提供给它们的数据，因此无论如何都不应该有任何逻辑要测试。

在我看来，视图的“测试”属于集成测试。（检查一切看起来都不错，链接到正确的地方等）

于 2012-05-03T10:48:55.357 回答