虽然在为一个ASP.Net MVC项目工作时练习了一些TDD，但我碰到了很多场景，我正在编写测试以确保特定的操作返回了正确的视图或具有特定的属性（如[ChildActionOnly]等）。 （事实上，我在这里发现了许多有趣的帖子，关于有用的扩展方法来帮助实现这一目标）。MVC - 单元测试错误的东西？
当我几年前在课程中首次介绍单元测试和TDD的概念时，强调强调测试应该关注测试逻辑落后于用户所需的特性和功能 - 如果您愿意，核心项目'要求'。
我的问题是 - 如果是这样的话，检查正确的视图文件被渲染的琐碎测试，或者具有特定属性的操作等并不真正包含单元测试方法的全部内容？我是否为错误的原因编写测试（即仅仅保护自己和其他同事避免重构错误）还是这些有效的有价值的单元测试案例？
如果一个处理程序方法可以根据某种逻辑返回两个（或多个）视图中的一个，那么声明正确视图的单元测试将会很有用。根据逻辑插入特定属性的处理程序方法也是如此。
我写测试错误的原因（即简单地保护其他 同事作出重构错误），或者是这些有效的情况下 有价值的单元测试？
捕捉回归错误是单元测试的好处之一，尤其是在重构时非常有用。如果您无意中更改了返回的视图，而进行一些重构，这对早期捕获非常有用 - 而不是等待仅在应用程序正在运行时才运行的测试。
如果您的操作根据某些逻辑返回不同的视图（或操作结果）。写一个测试。
如果你总是返回View（），那么不要。
如果您返回一个名称与您的动作名称不同的视图 - 那么您可能会认为编写测试是一个好主意。
这取决于。使用你的例子之一：检查一个动作是否有一个特定的属性是好的，但它更好编写一个测试，验证行为是否按预期运行，如果该属性丢失，将失败。
这就是说，最终你的测试是一个安全网。如果它有合理的机会阻止错误在未来的某个时候滑落，那么它正在完成它的工作。
如果这是一个简单的测试，开销很低，未来可能会随意破坏，那就去做吧。我宁愿有太多的测试，而不是太少。
事实上，你的测试应该测试你的逻辑。这不应该消失。但是，理想情况下，您应该为任何可能出错的地方编写测试。例如，确保所有需要保护的方法都具有适当的Authorize属性。这是一个安全测试。
终极，你决定什么是有用的你来测试。
我只想指出，不是“保护”同事，你的时间可能会更好地用于“指导”他们。你的同事们可能是尖锐的，只要一点点指导，每个人都会变得更好。我不是说没有单元测试，但是......进行修改后进行回归测试总是很好的。 – 2012-01-27 15:28:26