我谈到自己在采用传统TDD方式进行开发时感到有些尴尬，最后不得不放弃这种先写测试再写代码最后重构的方式。不过我还是非常注重单元测试的实践，慢慢发现自己的做法开始转向另一种TDD方式，也就是“可测试性驱动开发”。简单的说，我现在采取的做法是，先开发，再测试，一旦发现产品代码不太容易测试，则将其重构为容易测试的代码。我发现，这种时刻注重可测试性的开发方式，其最终也能够得到质量较高的代码。例如，它和SOLID原则也颇为融洽。上次谈的比较理论，而这次我便通过一个简单功能的开发过程，来表现我的思维方式及常用做法。
任务描述
这个功能是开发ASP.NET MVC项目时的常见任务：构建一个Model Binder。ASP.NET MVC中Model Binder的职责是根据请求的数据来生成Action方法的参数(即构建一个对象)。那么这次，我们将为负责产品搜索的Action方法提供一个 SearchCriteria参数作为查询条件：
public class SearchCriteria
{
public PriceRange Price;
public string Keywords {get;set; }
public Color Colors {get;set; }
}
[Flags]
public enum Color
{
Red = 1,
Black = 1 << 1,
White = 1 << 2
}
public class PriceRange
{
public float Min { get; set; }
public float Max { get;set; }
}
SearchCriteria中包含三个条件，一是复杂类型的Price条件，二是字符串类型的Keywords条件，三是一个Color枚举类型。作为查询条件，它总是需要在URL中表示出来的。例如，如果是这样的URL：
/keywords-hello%20world--price-100-200--color-black-red
它表示的便是这样的条件：
* 价格为100到200之间
* 关键字为“hello world”(注意URL转义)
* 颜色为黑或红(使用Color.Black | Color.White表示)
而最终，我要使用“可测试性驱动开发”来实现的便是这个方法：
public class SearchCriteriaBinder:IModelBinder
{
public object BindModel(ControllerContext controllerContext,ModelBindingContext bindingContext)
{
throw new NotImplementedException();
}
}
那么，我又会怎么做呢?
实现步骤
其实这也是个比较简单的功能，于是我一开始便用最直接的方式进行开发：
public class SearchCriteriaBinder : IModelBinder
{
public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
{
var modelName = bindingContext.ModelName;
var rawValue = bindingContext.ValueProvider[modelName].RawValue;
var text = HttpUtility.UrlDecode(rawValue.ToString());
var tokenGroups = this.Tokenize(text);
...
}
private List Tokenize(string text)
{
...
}
}
这个Model Binder会从Value Provider中得到Model Name(一般Action参数的名称，在这里不是重点)所对应的rawValue，经过了URL Decode之后便得到了text，它是一个带有信息的字符串，也便是《趣味编程》所要解析的对象。如上面的例子，text便是：
keywords-hello world--price-10-20--color-black-red
请注意，原本在URL中表示为%20的字符，已经被URL Decode为一个空格。在得到text之后，我便要将其拆分为一个List对象，这便是分割好的结果。拆分字符串的逻辑比较复杂，因此我将其提取到一个独立的Tokenize方法中去。于是我接下来就开始实现Tokenize方法了，写啊写，写完了。但是，我到底写的正不正确?我不知道。我唯一知道的东西是，这个逻辑不简单，我需要测试一下才放心。因此，在继续其他工作之前，我想要为它写一些单元测试。
这就是涉及到一个问题，我们该如何为一个私有方法作单元测试呢?我以前也想在博客上讨论这个问题，但是最终不知为何没有进行。我的看法是，如果设计得当，每个类的职责单一，应该不会出现需要进行单元测试的私有方法。如果一个私有方法需要测试，那么说明它的逻辑相对较为复杂，而且有独立的职责，应该将其提取到外部的类型中。例如在这里，Tokenize方法便值得我这样么做——因为我想要单元测试。于是我提取出一个Tokenizer抽象，以及一个默认的逻辑实现：
internal interface ITokenizer
{
List Tokenize(string text);
}
internal class Tokenizer : ITokenizer
{
public List Tokenize(string text)
{
...
}
}
我现在便可以对Tokenizer进行充分的单元测试，以确保它的功能满足我的要求。测试完成后，我就对它完全放心了。而此时，我的SearchCriteriaBinder便会直接使用Tokenizer对象，而不是内部的私有方法——当然，是基于抽象来的：
public class SearchCriteriaBinder : IModelBinder
{
public SearchCriteriaBinder()
: this(new Tokenizer()) { }
internal SearchCriteriaBinder(ITokenizer tokenizer)
{
this.m_tokenizer = tokenizer;
}
private readonly ITokenizer m_tokenizer;
public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
{
var modelName = bindingContext.ModelName;
var rawValue = bindingContext.ValueProvider[modelName].RawValue;
var text = HttpUtility.UrlDecode(rawValue.ToString());
var tokenGroups = this.m_tokenizer.Tokenize(text);
...
}
}
原本由私有的Tokenize方法负责的逻辑，现在已经委托给ITokenzier对象了，而这个对象可以在构造 SearchCriteriaBinder对象时通过构造函数提供。请注意，提供ITokenizer对象的构造函数访问级别是internal，也就是说，它可以被单元测试代码所访问(通过InternalVisibleToAttribute)，但是无法被另一个程序集的使用方调用。也就是说，经过重构的SearchCriteriaBinder，它的可测试性提了，但是对外的表现却没有丝毫变化。
经过简单思考，便可以发现这一简单的改变其实也较为满足SOLID原则中的一部分：
* 单一职责：SearchCriteriaBinder职责很单一，解析工作交由同样职责单一的Tokenizer进行。
* 依赖注入：这里使用了构造函数注入的方式，SearchCriteriaBinder对Tokenizer的依赖不是写死在代码里的。
* 接口分离：SearchCriteriaBinder并不直接访问Tokenizer，而是通过一个抽象(ITokenizer)使用的。
这便是我常用的“可测试性驱动开发”，我一开始只是按照惯例直接实现BindModel方法，然后发现一个需要测试的私有方法，因此为了提高可测试性，我将部分功能提取到独立的Tokenizer对象中去。在实际开发过程中，我也可能是直接在脑子里进行简单的分析，然后直接发现我们的确需要一个 Tokenizer方法(这点想象应该不难)，于是直接实现ITokenzier接口，Tokenizer类以及单元测试。这样，可能 SearchCriteriaBinder从一开始就会变成目前的样子。不过更多的情况，的确是写着写着，为了“可测试性”而进行的重构。为了说明这个 “思路”，我接下来还是使用“编写代码——尝试测试而不能——重构”的方式来进行开发。
