Question

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

为了使UI尽可能保持一致，让我们说初始团队开发了一种流畅的Html辅助方法，用于创建通用视图结构。即：

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

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

但即可。即使这些辅助方法中的每一个都可以进行单元测试，但我想知道自己测试视图有什么好处呢？

问题

我的观点是你没有对任何静态的单元测试（即视图）。因此，除非视图具有丰富的客户端功能，否则不应测试任何内容但如果确实如此，那么你将使用ie测试Javascript代码。 QUnit库。这种想法是正确的还是真的有意义来测试本质上是静态的东西，我们只测试某些元素及其内容的存在？
可以测试哪些其他方面的视图以及为什么要测试它们？

在我的开发过程中，我注意到单元测试只能在非平凡的代码上进行。换句话说，应该测试至少有一个分支的方法，以及其他足够长的方法，即使没有分支，它们也不会完全明显。

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

Answer 1

视图应该只显示提供给他们的数据，因此不应该有任何逻辑进行测试。

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

什么时候应该对Asp.net MVC视图进行单元测试

问题

1 个答案: