在为 ASP.Net MVC 项目练习一些 TDD 时，我遇到了很多场景，在这些场景中，我正在编写测试以确保特定操作返回正确的 View 或具有特定的属性([ChildActionOnly ] 等)。 (事实上，我在这里发现了一些有趣的帖子，关于有用的扩展方法来帮助实现这一点)。
几年前，当我第一次在类(class)中了解到单元测试和 TDD 的概念时，强调的重点是测试应该侧重于用户背后的测试逻辑-所需的特性和功能 - 核心项目“要求”，如果您愿意的话。
我的问题是 - 如果是这种情况，是否进行了琐碎的测试来检查要呈现的正确 View 文件，或者具有特定属性的操作等是否没有真正包含单元测试方法的全部内容？我是出于错误的原因编写测试(即只是为了保护自己和其他同事不犯重构错误)还是这些有值(value)的单元测试的有效案例？
最佳答案
如果处理程序方法可以根据某些逻辑返回两个(或更多) View 之一，那么断言正确 View 的单元测试将很有用。根据逻辑插入特定属性的处理程序方法也是如此。
Am I writing tests for the wrong reasons (i.e. simply protecting other colleagues from making a refactoring mistake) or are these valid cases of valuable unit tests?
捕获回归错误是单元测试的好处之一，在重构时尤其有用。如果您在进行一些重构时无意中更改了返回的 View ，这对于及早发现非常有用 - 而不是等待仅在应用程序运行时运行的测试。
关于c# - MVC - 单元测试错误的东西？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9034560/