原文地址：Building a Simple Blog Engine with ASP.NET MVC and LINQ - Part 4
摘要
在本系列的第四篇中，Keyvan讨论了与MVC模式相关的单元测试的概念，以及微软是如何将这些概念应用于其ASP.NET MVC框架中的。他提出了对ASP.NET MVC应用进行单元测试必须遵循的原则和过程。
内容
- 简介
- 单元测试概述
- 为什么使用MVC？为什么使用ASP.NET MVC？
- ASP.NET MVC中的抽象与隔离
- MVC模式中的测试过程
- ASP.NET MVC Preview 2中改进的测试特性
- 其他部分
- 小结
简介
在本系列的前三篇中，我讨论了MVC模式中的主要概念、ASP.NET MVC框架以及KBlog（本系列中创建的简单Blog引擎）。目前为止，我讨论了MVC模式中三个核心组件中的两个：控制器和数据模型。
Web开发者（不止是ASP.NET开发者）对MVC模式“趋之若鹜”的主要原因是，它赋予了开发者测试Web应用的能力，使得测试变得更加简单。因此，Web应用也可以进行单元测试了。
当然，对于传统的Web应用也不是不能单元测试，只是MVC模式下要简单得多。
本节和下节的话题都是单元测试。在MVC模式中，你可以仅测试控制器类。在演示如何对MVC应用进行单元测试之前，我们先从基本概念入手。
在开始正题之前我需要指出的是，本系列前三篇是基于ASP.NET MVC框架的第一个发布版本CTP的，而本文则基于第二个CTP版本。
单元测试概述
测试驱动开发（TDD）是当今最普遍的软件开发方式。敏捷开发方法的兴起以及小型软件开发团队如雨后春笋般的增多，是TDD作为软件开发首选方法的主要原因（当然还有其他的原因）。
因为显然我不可能在这里讲述太多TDD和单元测试的东西，因此我假设读者已经有了这方面的背景。但是，一个简短的介绍还是有必要的。
TDD最核心的部分就是单元测试。单元测试是将应用划分为小的不相关的可以独立工作的单元，并对这些单元进行测试的一组技术和过程。
单元测试基于以下一些原则。首先，将应用划分为更小的更便于测试的部分。其次，这些单元彼此之间相互独立互不影响。这种独立性使得对一个单元的更改不会波及到其他单元。
单元测试对这些小的单元进行测试，看它们对于不同的环境和输入数据是否都会按预期执行。这样，全部单元测试通过之后，就可以开始下一阶段的开发了。如果你修改了其他元素或单元并破坏了现有代码（这并不稀奇），那么现有的测试将不会通过，同时发出警报。
因此，你可以反复修改重构代码而不会破坏其连贯性。这也是众多开发人员选择单元测试的主要原因。
然而，我无法对测试驱动开发和单元测试进行过多的描述，当然我也不会那么做。但我只是想说，有很多方法可以对数据层、抽象代码和Web服务进行单元测试。同时，也有很多优秀的模式和实践方面的文档，描述如何编写使单元测试过程更加简单的代码。
为什么使用MVC？为什么使用ASP.NET MVC？
Web开发是一个需要自身技术和模式的普通开发场景。由于Web开发与多项服务器技术如Web服务器属性或客户端请求细节等息息相关，软件开发者需要寻求一条途径以降低这些依赖。基于以上介绍，你知道为什么了吗？
原因就是“隔离”。我们需要降低依赖来改善隔离等级。解决方案就是引进新的开发模式（如MVC）。最著名的为MVC量身打造的技术就是Ruby on Rails，这也是Ruby之所以流行的原因之一。
Web开发技术的发展使得微软开始考虑改变ASP.NET技术以适应该模式，ASP.NET MVC Framework应运而生。
总而言之：
- 单元测试很棒（在我看来，它应该成为软件开发的一部分）。
- 单元测试需要对应用中不同的但愿进行高等级的抽象和隔离。
- 传统的ASP.NET Web Form应用对HttpContext、HttpRequest和HttpResponse之类的对象有很强的依赖。
- 微软需要在其Web开发技术中适应MVC。
- 微软需要降低所有依赖并提升隔离等级。
- 因此，考虑到隔离和抽象，微软需要构建ASP.NET MVC模式。
因此，ASP.NET MVC Framework伴随着一些主要的ASP.NET类（如HttpContext、HttpResponse或HttoRequest）的重新设计，而悄然诞生。
ASP.NET MVC中的抽象和隔离
我们需要良好的抽象和隔离，但在设计和编码时应该如何做到这一点呢？抽象类和接口为我们提供了很好的方案。
单元测试与抽象基类和接口是很紧密的，并且有很多的模式和实践。我不想在这个话题上深入下去。
当使用抽象类和接口来进行抽象时，你可以很简单地测试这些类的实例，因为他们拥有共同的主要方法。在单元测试时这是十分有用的，因为它使你能更好地控制在单元测试中扮演某些角色的类。
但是如何选择使用抽象基类还是接口呢？尽管它们都可以为我们提供抽象，但也都存在一些局限性。
我的朋友，微软ASP.NET MVC团队成员，Phil Haack，发表了一些博客解释这些局限性。并且，他们在第一个CTP版本的ASP.NET MVC Framework中所面对的接口的局限，使得他们在第二版甚至以后所有的版本中都选择了抽象基类。
- Versioning Issues With Abstract Base Classes and Interfaces
- Abstract Base Classes Have Versioning Problems Too
- The Cost Of Breaking Changes
然而从最终用户的角度来看，你不必郭宇关心这些问题。
但最终，微软在第二个发布版本的ASP.NET MVC中使用了抽象基类。
你将看到这些改变有助于你在下面的章节中对ASP.NET MVC应用进行单元测试。
微软将所有的抽象类移动到一个新的程序集System.Web.Abstractions中，你可以反编译该程序集中的类。
图1按层次和结构展示了这些类，你可以对其抽象级别有些了解。
图1
如图所示，有7组基类及其派生类。每个抽象基类都代表了一个包含很多依赖的传统的ASP.NET类。因此这种抽象有助于单元测试过程，你将在下一节中有所了解。
简而言之，我们可以将这些类归为7种类型：
- HttpSessionState
- HttpServerUtility
- HttpContext
- HtpResponse
- HttpRequest
- HttpBrowserCapabilities
- HttpCachePolicy
如你所见，所有的类型都与服务器、客户端属性和特性联系紧密。但这种抽象有助于降低依赖性并改进易测性。
MVC模式中的测试过程
ASP.NET MVC中的测试过程是什么样的呢？MVC模式的设计将应用的架构划分为相互独立的组件（模型、视图和控制器），这简化了测试的过程。其理念就是，将应用划分为这些组件以限定对控制器组件的单元测试。
换句话说，只需要测试MVC中的控制器类，这就足够了。
控制器是纯粹的程序类，与数据模型和视图（数据层和用户接口层）完全独立。这种独立性可以使你通过测试控制器来测试应用程序。
下一篇将讨论如何测试控制器。
ASP.NET MVC Preview 2中改进的测试特性
ASP.NET MVC的新版本（Preview 2）（目前的最新版本为ASP.NET MVC 1.0 RC）提供了一些新的特性帮助开发者改善测试能力。一个主要的改变就是可以在创建ASP.NET MVC项目的同时创建集成的单元测试项目。在此之前，你只能先创建ASP.NET MVC项目，然后再手工创建单元测试项目。而现在Visual Studio会询问你是否新建Visual Studio单元测试项目。
如图2所示。在创建ASP.NET MVC项目之后，将会显示该对话框询问你是否创建测试项目。
图2
当然，你可以忽略它，不创建单元测试项目。
另一方面，Visual Studio测试框架（MsTest）并不是唯一的选择。许多职业程序员选择其他测试框架如NUnit、MbUnit，他们都是.NET开发者所熟知的。
其它部分
- Building a Simple Blog Engine with ASP.NET MVC and LINQ - Part 1
- Building a Simple Blog Engine with ASP.NET MVC and LINQ - Part 2
- Building a Simple Blog Engine with ASP.NET MVC and LINQ - Part 3
小结
本系列的第四部分全部是关于单元测试的概念，它使得在ASP.NET MVC应用中进行测试驱动开发成为可能。这也是MVC模式的主要优点之一。
我先介绍了在MVC模式中进行单元测试的重要性，然后简要介绍了单元测试以及主要目标，然后深入创建ASP.NET MVC Framework的过程。这之后，讨论了抽象和隔离的必要性，以及在ASP.NET MVC Framework中是如何做到这一点的。
在这篇文章中，我没有涉及到任何关于KBlog，有关该理论概念的所有应用程序也留在了下一篇中。在使用MVC模式以及ASP.NET MVC Framework时，对单元测试概念的理解是很重要的部分。
在本系列的下一篇中，我将对KBlog中的控制器进行单元测试，对单元测试的理论进行实践。