我是新的Asp.Net MVC和单元测试，所以如果问题有些愚蠢我会提前道歉
单位测试传入路由时，我们必须将网址提供给路由系统，并验证是否正确处理了此网址。
1）但是应该单独测试路由（因此特定的单元测试将测试不超过一条路由）或所有路由作为一个整体进行测试（即每个单元测试将测试RouteCollection.GetRouteData(...);）或两者返回的实例？
2）如果 1）的答案是 routes 应该作为一个整体进行测试，那么我很难理解我们需要传入多少个URL 路由系统以确保其正常工作：
a）据我所知，我们不需要传递与注册路径一样多的URL，其中每个URL都应由一个不同的路由（这样所有路由都有机会处理一个URL）？
b）是否应在单一单元测试中测试所有网址，或者我们是否应为每个网址进行一次单元测试？如果是后者，则单元测试的数量不会与每个单元测试测试不超过单一路径相同 EM>？
c）假设我们将新路由添加到路由系统，那么我们很可能还需要修改现有的单元测试为了让他们继续正常工作，而如果我们分别测试路线，那么不需要修改现有的单元测试吗？
谢谢
答案 0 :(得分：0)
你应该小心这些类型的测试，因为你很容易最终测试Asp.Net MVC代码，这是微软可能做的事情。 （例如：这些测试不会测试GetRouteData方法的功能吗？）
除非我误解你，否则你只是想确保正确配置路线数据。
我认为这种类型的配置代码只是creating your application's object graph的一部分，不受单元测试的影响。这有几个原因：
配置可能发生在合成根目录中（例如，Application_Start中的global.asax内）。
任何配置都会将系统初始化为＆＃34;技术上正确的＆＃34;州。 （就像你用一个test double替换了一个生产组件。系统工作;它只需要为生产配置不同。）
这些配置很可能在将来发生变化。例如，您提到可以在以后添加新路由。现有路线也可能会发生变化。
端到端/ Smoke testing将确保应用程序不会返回404，这通常会在路由数据配置不正确时发生。
< / LI>在考虑了这一点之后，如果您在测试配置时仍然没有考虑，那么请考虑创建一个处理此配置的抽象。也就是说，create a seam位于您注册这些路线的边界。
这将允许您模拟对Asp.Net MVC框架的调用，并验证您是否正在向其发送预期的配置。