前言：最近正在研究一个新项目的开发工作，这个项目的要求是必须写UnitTest，对于我个人来讲是很不喜欢写UnitTest的感觉这个东西会很大程度的延误开发进度，所以之前项目的UnitTest是能不写就不写，好在作坊式的开发不在乎你写不写，功能Work就OK了，好多技术大拿都对UnitTest情有独钟，可能对于我这种码农来说无法理解其好处吧，小小抱怨也无力改变什么，只能研究研究UnitTest了。
当我在VS12中想通过右键找到Create UnitTest这个选项的时候，我发现10中给写UnitTest带来极大方便的选项在12
13中竟然没有了(也可见我多久没写UnitTest了lol)，为什么微软要将这个功能取消了呢，我个人认为是为了更好的满足TDD的开发模式，微软对于TDD的开发模式可以说是大力的支持，甚至用VS
2012的开发团队为模板来向我们这些屌丝程序员来展示什么是优雅的C#开发。那何为TDD呢，下面切入正题来说说我的一点理解。
TDD(测试驱动开发)
是测试先行的方式，也就是说根据需求写驱动（写测试用例）。通过用例从红灯变成绿灯，使其通过了把实现的代码生成出来。通常我们的开发模式是先写完Code，然后Create
UnitTest，此种方式属于测试后行。对于此两种方式，我个人感觉不能说就一定要TDD而完全否定测试后行的方式，但是TDD给我们带来的方便是今天想要谈的主题，对于两种方式的讨论，欢迎大家来辩。
TDD此种方式最有意义的地方在于：不会因为你先去想代码实现而产生过度设计的问题，如果从实际的需求出发，你写出来的代码是最简单，最直接满足需求的方式，就不会产生过度设计的问题。在这里我同样想到了一种编程方式：结队编程，结队编程是一种将知识传播下去的方式，意思是熟悉此处逻辑的老人可以和新人一起来编写一块逻辑，通过去修改BUG，写代码，老人带着新人将这块一起做下来，包括新成员进来的时候可以通过此种方式将知识传播下去。这也是一种Code
Review，两个人一起看，总比一个人看发现问题的机会要多一些，因为两个人的思路是不同的，总是一个人开发是有问题的。因此此处是想将结队编程和TDD结合的方式。一个人写Test
Case，另一个人通过Test Case来写实现。下面就通过实际的例子来演示一下（演示的代码没有实际意义，只是想通过例子来展示结队编程和TDD结合）。
比如说我们现在有一个需求求一个圆的周长，那我们需要设计两种用例，1、输入一个整数值，通过计算返回周长。2、输入一个负值，抛错。下面我需要两个人来结队通过TDD方式来实现这个Story，为了方便理解，我用大话设计模式的人物命名方式来指定两个开发人员，老鸟，菜鸟。
老鸟：我写一个类Circle，写好它的构造函数。
private int _r;
/// <summary>
/// TODO: Complete member initialization
/// </summary>
/// <param name="p">radius</param>
public Circle(int r)
{
this._r = r;
}
然后我开始写UnitTest，先创建一个UnitTest工程，然后写Test Case，写好后生成Caculate方法，设置断言，想得到正确结果。
[TestMethod]
public void TestPerimeter_FirstCase()
{
Circle worker = new Circle(1);
double result = worker.Caculate();
Assert.AreEqual(result, 6.28);
}
此时，我Run Test，结果是通不过，因为我的Caculate方法还没有实现，小鸟，那你来实现这个方法。
小鸟：so easy，分分钟搞定。
private int _r;
private readonly double _pi = 3.14 * 2;/// <summary>
/// TODO: Complete member initialization
/// </summary>
/// <param name="p">radius</param>
public Circle(int r)
{
this._r = r;
}public double Caculate()
{
return _r * _pi;
}
老鸟：OK，现在我们再Run Test，果然我们这个Case通过了。那我再写一个Test Case。
[TestMethod]
[ExpectedException(typeof(ArgumentException))]
public void TestPerimeter_SecCase()
{
Circle worker = new Circle(-1);
double result = worker.Caculate();
}
再Run Test，又失败了。
小鸟：哦，因为没有对参数进行判断，没有考虑小于零的情况，我修改下Caculate方法的实现。
public double Caculate()
{
if (_r < 0)
{
throw new ArgumentException();
}
return _r * _pi;
}
这样两种Case就全通过了。
这个小例子就算结束了，可以看出来，我们通过TDD的方式，根据Test
Case来设计代码逻辑，可以使我们的逻辑没有任何过度设计，而且这样的方式使UnitTest的代码覆盖率很高。