从企业的运行价值链说起——我眼中的测试驱动开发(TDD)

本篇转自cnblogs，作者wayfarer．
原文章地址: 从企业的运行价值链说起——我眼中的测试驱动开发(TDD)

        本周看了中央电视台的《对话》栏目，节目对三星CEO尹钟龙进行了访谈。其中，现场一位女士的一句话令我印象深刻。她提到一个企业的运行价值链，共分为三步：首先是发现价值，找到目标市场；第二步是生产价值，将高质量的产品生产出来；最后是保护价值或收获价值，做好品牌。

        怎么理解呢？这位女士以Nike作比喻。第一步是设计Nike鞋，这就是发现价值，可能获得100美元的价值；然后再拿到中国来生产，大约是10美元；最后再将生产好的鞋子，贴上Nike的商标送回到美国去卖，又可以收获90美元。一双鞋售价200美元，而生产价值所能收获的却只有10美元。这一步获取利益最低，我们中国的公司却做得最好。而怎么去发现价值，然后又怎样去巩固自己的品牌和知名度，中国的公司就做得不那么好了。

        最近我们团队就测试驱动开发开展了一次技术交流。看了交流的记录以及评论，得到一个普遍的结论就是：测试驱动开发是个好东东，但似乎不符合中国国情。很多人都提到了原因，说得最多的一条，就是项目时间紧，没有时间写测试代码。在项目中，到底该不该使用TDD，大多数人持怀疑或观望的态度。这种态度与观点，就让我想起了如上《对话》中的这一段话。

        仔细分析企业运行价值链的三步走，我觉得和软件开发的TDD价值链很相似。第一步，是发现价值。应用到TDD中，就是测试先行，通过测试来驱动我们编写代码。第二步，生产价值。毋庸置疑，这正是编写代码的一个阶段。而第三步，就是收获价值，在TDD中，我们收获的不仅有开发后完整的产品，同时还收获了完整的测试套件。和Nike鞋的生产一样，我们在软件开发中，过度地重视了第二步生产价值阶段，而对于第一步和第三步，要么是忽略了，要么就是没有提高到相应的高度。

一、发现价值与生产价值

        习惯了传统开发模式的程序员，非常不适应写代码之前，先写测试的方法，这其中也包括我。那么，我们一般是怎样去发现价值的呢？首先通过需求分析，然后进入设计阶段。在设计阶段期间，再围绕需求分析的结果，更多的是从实现的角度，而非从客户应用的角度出发。TDD颠覆了这种模式。因为需要测试先行，就驱动了程序员必须从功能出发、从应用出发。在写测试代码的过程中，我们需要考虑要实现那些功能，相应的类的名称、对象的创建方式，以及可能会应用到的模式和策略，如此种种，在这个过程中，如剥笋子一般逐渐地规定出来了。

        在这个过程中，我们要审慎地选择测试的步子。昂首阔步虽然显得气势轩昂，行进快速，但往往会忽略沿途的风景。在测试驱动开发中，我建议你小心的规划测试样例，从测试样例的逐步完善中，渐进地驱动出你更加完善的代码。例如，我需要开发一个智能的个人助理，它目前能提供的功能是：能够让用户定制自己感兴趣的类别，然后个人助理根据用户的定制进行搜索，并将搜索得到的结果按不同的类别进行存储。

        我们来尝试一下TDD的过程。根据对功能的分析，我们首先应该有一个智能助理对象，测试代码如下：
[Test]
public void TestSmartAssistor()
{
 SmartAssistor assistor = new SmartAssistor();
 Assert.IsNotNull(assistor);
}
        当然，这段代码是连编译都无法通过的，我们还需要创建SmartAssistor类型。然而，不要小瞧了这一步，它实际上促使你对项目进行初步的理解，至少，你需要想好这个将要创建的类型，它的名字是什么？这就是一种驱动力。（为了简便起见，在本文只列出测试代码）

        然后，这个类型能够做些什么呢？我们把个人智能助理的功能进行分类，应该包括三个功能：
1、 定制；
2、 搜索；
3、 存储。

        仔细想想，实际上只有搜索和存储才是智能助理的职责所在，而定制不过是智能助理要运转的一个条件罢了。既然如此，从客户应用的顺序来考虑，我们应该先实现定制的功能。要定制类别，就应该具备类别类型，而定制类别这项功能，则应该由一个专门的控制器来承担责任。
[SetupUp]
public void InitObject()
{
 Category cg1;
 Category cg2;
 CategoryContainer cgContainer;
SmartController control;
}

[Test]
public void TestCategory()
{ 
 cg1 = new Category("SoftWare Engineering","TDD");
 cg2 = new Category("SoftWare Engineering","Design Pattern");
 cgContainer = new CategoryContainer();
 cgContainer.Add(cg1);
 cgContainer.Add(cg2);
 
 Assert.IsNotNull(cgContainer);
 Assert.AreEqual(cg1,cgContainer[0]);
 Assert.AreEqual(cg2,cgContainer[1]);
}

[Test]
public void TestController()
{
 control = new SmartController();
 Assert.IsNotNull(control);
 Assert.IsTrue(control.CustomizeCategories(cgContainer));
}

        上面的测试代码完全从用户的应用角度来考虑的。要定制类别，必须具备类别类型Category，它应该实现一个带参的构造函数，传递主类别和子类别。由于定制的类别可能会很多，所以需要一个类别容器CategoryContainer。

        而定制类别，则由控制器SmartController完成。定制的方法CustomizeCategories()定制多个类别，并返回布尔型，以确定定制是否成功。通过上述的测试代码，写出相应的程序应该不难吧。

        接下来应该考虑搜索和存储功能了。在前面我提到，这两个功能应该是SmartAssistor类型的职责。先修改最初的测试代码：
[Test]
public void TestSmartAssistor()
{
 SmartAssistor assistor = new SmartAssistor();
 Assert.IsNotNull(assistor);
 assistor.Search(control.Categaries);
 assistor.Store();
}

        此时，我发现在写Search()和Store()方法的断言时，有些问题存在。这两个方法返回的结果应该是什么？是布尔值吗？那么搜索得到的结果呢？存储后形成的文件呢？对于用户而言，是否只需要这两个行为呢？

        仔细分析，我认为，Search()和Store()方法返回布尔值是可行的，但Search()还应该返回搜索结果。Store()方法也应该指定存储的路径和文件的格式。而用户不仅仅需要搜索和存储，同时还应该提供显示的功能。所以，上面的测试代码需要完善：
[Test]
public void TestSmartAssistor()
{
 SmartAssistor assistor = new SmartAssistor();
 Assert.IsNotNull(assistor);
 
 SearchResult result = new SearchResult();
 Assert.IsTrue(assistor.Search(control.Categaries,out result));
 Assert.IsTrue(assistor.Store(result,@"D:/Smart Assistor/","result.xml"));
 
 assistor.List(result);
}

        此时根据测试代码写出的程序，应该说就具备个人智能助理的雏形了（所谓智能，还应具备自动搜索，自动匹配，自动分类等诸多功能，本文只是根据该项目提出TDD的一些观点，因此这些功能省略）。

二、通过TDD进行重构

        “发现价值”的过程远远没有结束。通过测试代码，我们从客户的角度来考虑，会发现一些问题。在已经实现的代码中，SmartAssistor类型实现了Search，Store和List的功能。但这些职责是否真的应该由它承担呢？表面上来看，是这样的。然而根据OO的思想来看，这个SmartAssistor所承担的责任是否太多了？它和搜索的结果、显示的方式耦合度是否太紧密了？这个设计将实现抽象出来了吗？这些都应该是我们考虑的重点。考虑的时机，可以是设计之初，也可以是重构之时。

        在重构的时候，仍然不能放弃TDD，只有它才能保证程序的可靠性，重构的正确性。开始重构吧。

        首先从行为来考虑。搜索的功能会很复杂吗？可能会有精确搜索，模糊搜索；可能是在网上搜索，也可能是本机搜索。那么，存储的功能呢？IO的操作是否频繁，存储的要求是否会根据安全级别而逐步升级？再考虑显示，对于个人智能助理来讲，显示的方式需要多样化吗？显然，以上的行为都是复杂的。

        再从抽象性考虑。需要把这些行为抽象出来吗？也就是说，这些行为的载体是否会有多种类型？显然，搜索可能会是文件的搜索，可能会是文本的搜索，也可能会是数据库的搜索；存储的格式也会有多种多样，文本文件，xml文件，数据库文件。显示的方式可能会通过浏览器显示，也可能会在WinForm中显示。也许用户要求是带滚动条的文本框，也许只是简单的文本显示。对象的形式很多吧，需要抽象吗？显然是的！

        这样考虑之后，我发觉需要重构的东西太多了，应该怎么入手？首先，我们把SmartAssistor的职责先剥离出来，用更单一的对象来完成各自的功能。例如我们可以引入SmartEngine来管理搜索功能。然后，分别将这些对象提炼出各自的接口。还是先写测试代码吧，考虑搜索功能，首先需要将对象分离出来：
[Test]
public void TestSearching()
{
 SearchEngine engine = new SearchEngine();
 Assert.IsNotNull(engine);
 
 SearchResult result1 = new SearchResult();
SearchResult result2 = new SearchResult();
 Assert.IsNotNull(result1);
 Assert.IsNotNull(result2);
 result1 = engine.ExactSearch(control.Categaries);
 result2 = engine.BlurSearch(control.Categaries);

 SearchResult tempResult1 = new SearchResult(control.Categaries,"contents"); 
 SearchResult tempResult2 = new SearchResult(control.Categaries,"more contents"); 
 
 Assert.AreEqual(tempResult1,result1);
 Assert.AreEqual(tempResult2,result2);

}
        在NUnit中运行测试代码，未能通过。然后在程序中创建SearchEngine类型，并实现ExactSearch和BlurSearch方法。直到在NUnit中运行通过，全部显示绿灯。

        接下来抽象出SearchEngine的接口ISearchEngine，并让SearchEngine实现该接口。其中接口方法包括ExactSearch和BlurSearch方法。将前面的测试代码作小小的修改，修改后同样需要在NUnit中运行，保证顺利通过：
[Test]
public void TestSearching()
{
 ISearchEngine engine = new SearchEngine();
 Assert.IsNotNull(engine);
 
 ……

}

        考察SearchEngine类型，该类型的对象应该在整个程序中只保留一个对象，因此，应对此采用单例模式。修改测试代码：
[Test]
public void TestSearching()
{
 ISearchEngine engine = SearchEngine.Instance;
 Assert.IsNotNull(engine);
 
 ……

}
        根据测试代码修改程序代码，将SearchEngine类型的构造函数改为private，并提供只读的静态属性Instance，以此来获得单例对象。

        仅仅是这样还不够的。考虑到搜索的范围有多种情况，如internet，local machine，DB等。SearchEngine类型应该具体化不同类型，并同时实现ISearchEngine接口。例如搜索范围在internet，测试代码如下：
[Test]
public void TestInternetSearching()
{
 ISearchEngine engine = InternetSearchEngine.Instance;
 Assert.IsNotNull(engine);
 
 ……

}

        既然有如此多的类型，类型的创建就必须通过工厂进行管理。此时测试代码需要做进一步的修改：
[Test]
public void TestInternetSearching()
{
 ISearchEngineFacotry fatory = new InternetSearchEngineFactory();
 ISearchEngine engine = factory.CreateInstance();
 Assert.IsNotNull(engine);
 
 ……

}
        同理，我们应该分别实现测试方法TestLocalSearching()和TestDBSearching()。

        按照这样的思路，分别对存储功能和显示功能进行重构。记住，每做一步重构，都需要严格按照TDD的方式。首先写出测试代码，然后在NUnit运行。如果是红灯，需要写出相应的代码，再运行NUnit，直到全部均为绿灯为止。

三、第一步的小结

        表面上看，这样繁复地写测试代码，程序代码，确实是有些Kill Time了。但我们需要认真地思考所谓“发现价值”的意义。通过测试先行的方式，以模拟客户应用的状态来考量客户的需求，并通过此驱动程序员一步一步地到达“生产价值”的终点。“发现”与“生产”并行不悖，同时“质检员”一直跟随其间，保证了产品的质量。

        就好比Nike鞋的生产，必须以体贴用户的角度出发，设计出吸引人的样式，那么大规模的生产才会有盈利的可能。

        TDD的生产过程也许慢了一点，但请不要忽略了它其实已经省去了编码后单元测试的时间。相加相减之后，又会浪费多少时间呢？所以，千万不要以“时间紧”的理由来搪塞我哦。

四、考察第三步——收获价值

        传统的方式，在产品生产出来之后，紧接着的是大量的测试，其中也包括单元测试；最后收获了产品、一大堆源代码和文档。而TDD的方式，既省去了单元测试的过程，同时还收获了另外一样上帝赐予的礼物——测试类或测试套件。

        测试类绝对是一件奇妙的礼物。必须认识到它的价值不只是在于“发现价值”的阶段，它同样是我们的“收获”。

第一：比代码更好的文档、比文档更好的代码
        有了它，不用钻进浩如烟海的文档里，四顾茫然了。文档的文字描述既不准确，容易产生歧义，又容易产生文档同步的问题。也许它能促进你对业务和架构的理解，但对于程序本身，你无法从文档中得到基本的启示。

        那么看程序的源代码吗？你会在众多的类对象和方法中绕来绕去，最后一头雾水，精疲力尽之后，还是一无所获。

        而看测试代码就不同了，你不需要了解每个方法的具体实现，因为测试代码是从客户的应用角度来书写的，看完测试代码，你会很轻松地理清程序结构的脉络。

第二：新兵训练营的绝佳教材
        也许你的项目组新进了员工，如果他熟悉TDD，那么，这些测试类是他熟悉项目的最好文档；如果他还没听说过TDD，不用着急，先把这些测试类给他。只要他不是程序设计的新手，我想这个新兵会很快熟悉项目组开发的方式。再让他写几个测试样例，他会立即投入到TDD的怀抱中来的。

第三：满载而归的信心
        项目开发中，成员最宝贵的除了认真、努力、团队精神之外，就是信心了。这里所谓的信心，并非是对自己能力充满乐观的估计和客观地评价后，表现出来的精神面貌，而指的是程序员对代码正确性的信心。无论这些代码是自己写的，还是他人写的，只要严格按照TDD的要求进行，你都会对它们充满信心。虽然不能保证没有bug，但必须承认的是通过单元测试，我们已经将bug降低到最小了。

五、结论

        中国企业在企业运行价值链上，走好了利润最低的第二步，却忽略了“发现价值”和“收获价值”对于一个企业的重要性。韩国三星在几年之前还是一个亏损600多亿美元的企业，如今它已经成功地扭亏为盈，并跻身世界五百强。原因很多，但不可忽视的是，他在价值链的首尾两步中作得很好。从高端产品中发现价值，找到了目标市场；从品牌创造中收获了价值，走向了世界。

        我不是说软件开发一定要采用TDD的方式，它自然也有很多缺陷。然而，我们在开发的过程中，同样要重视设计的“发现价值”阶段，然后在收获产品的同时，不要忽略了还应该收获其他同样值得珍视的“价值”。从这一点来看，也许TDD更符合这种价值链的模式。而我们程序员千万不要舍本逐末，过于偏执地重视“生产价值”，以致于在软件开发方法上，总是落后于人，进而受制于人!

        最后，谨以我之愚见，思考TDD的方式，认为TDD内力精深，大约分为四种无上之力：
1、 驱动力——驱动程序代码编写；
2、 学习力——新兵训练营之绝佳教材；
3、 自信力与他信力——bug降到最低；
4、 控制力——与重构紧密接合，牢牢控制开发过程；

注：本文代码仅为说明TDD的实现而写，非实际的项目代码，不保证其一定能通过编译。