如何通过ASP.NET Abstractions提升ASP.NET应用的可测试性？

本文共计2732个文字，预计阅读时间需要11分钟。

概述+在阅读本文之前，请先注意两点：+我们讨论的是传统ASP.NET应用的可测试性，而不是ASP.NET MVC应用的可测试性。+我们在这里说的增强，而不是指传统ASP.NET应用。

概述

在阅读本文之前，兄弟们请先注意两点：

• 我们现在谈的是传统ASP.NET应用程序的可测试性，而不是ASP.NET MVC应用程序的可测试性。
• 我们现在谈的是“增强”，而不是说传统ASP.NET应用程序做不到良好的可测试性，一切皆在人为。

关于可测试性的重要性，老赵觉得已经不需要再过多强调了。如果您想要获得高生产力，为代码编写单元测试似乎已经是必经之路了。不过可惜的是，ASP.NET应用程序给人的感觉，始终是对可测试性不太友好，其最重要的原因之一在于对HttpContext对象的高度依赖，而我们很难对HttpContext编写Mock或Stub：对于最常见的Mock框架来说，进行Mock的方式在于对抽象类型进行继承和重写，因此需要目标类型必须能够继承，其成员也必须能够重写（override），可惜HttpContext对这两个要求均不满足——虽然我们有TypeMock这个强大的工具，只可惜它是商业产品。而且事实上，如果Moq等框架无法满足您的要求，一般可以确定是设计有问题。从这个角度说，ASP.NET围绕HttpContext开展的一系列功能，在设计上的确有不足之处。

因此，为了提高ASP.NET应用程序的可测试性，各方都作了许多努力，其中的原则便是：尽可能减少对HttpContext的依赖（不可测试的逻辑），使逻辑依赖于特定的抽象类型。