测试驱动开发指南
Jeffrey Palermo
2006年5月
摘要：通过本文，读者可以了解如何结合Visual Studio Team System应用敏捷开发方法学里所强调的重点——测试驱动开发。
内容
简介
应用案例
测试驱动开发的优点
一个好的单元测试应具备的特点
结论
参考资料
简介
应用案例
测试驱动开发的优点
一个好的单元测试应具备的特点
结论
参考资料
简介
测试驱动开发（TDD）是一种先进的技术，通过使用自动化单元测试来驱动软件设计并强制依赖的松耦合。使用这一技术的结果是一整套单元测试集合，而且这些单元测试可以在任何时间被运行，以验证软件是否还正常工作。这一技术被那些应用敏捷开发方法学的人士推崇备至。为了在Visual Studio Team System里面使用该技术，你必须理解下面几个地方：
• 在VSTS IDE里面创建并运行自动化测试
• 在面向对象世界里将依赖抽象化
• 重构新老特性以清楚代码中的冗余
• 如何写单元测试？
• 如何组织测试列表？
• 如何运行选择的测试？
测试驱动开发（TDD）是一种先进的技术，通过使用自动化单元测试来驱动软件设计并强制依赖的松耦合。使用这一技术的结果是一整套单元测试集合，而且这些单元测试可以在任何时间被运行，以验证软件是否还正常工作。这一技术被那些应用敏捷开发方法学的人士推崇备至。为了在Visual Studio Team System里面使用该技术，你必须理解下面几个地方：
• 在VSTS IDE里面创建并运行自动化测试
• 在面向对象世界里将依赖抽象化
• 重构新老特性以清楚代码中的冗余
• 如何写单元测试？
• 如何组织测试列表？
• 如何运行选择的测试？
单元测试开发的箴言就是“红、绿、重构”
• 红：创建测试，但无法通过
• 绿：使测试被任何必要的方法验证通过
• 重构：修改代码以清楚你项目中的冗余，在确保所有测试仍然可以通过的情况下修正软件的设计
• 绿：使测试被任何必要的方法验证通过
• 重构：修改代码以清楚你项目中的冗余，在确保所有测试仍然可以通过的情况下修正软件的设计
红/绿/重构圈在每个新的代码单元出现时不停地被重复使用。
应用案例
在你使用VSTS时，下面的几个步骤在你处理一个业已提供给你的工作项时会被遇到：
• 确保在你要创建新测试的解决方案里有一个VSTS测试项目。
依照以下步骤执行（对不同的TDD开发者可能稍有不同）：
1.理解故事、工作项或者现在使用的特性的需求。
2.红：创建一个测试，但无法通过。
a.想象一下新代码是如何被调用的，然后写一个测试，就好像这段代码已经存在一样。这儿你不会得到只能提示，因为新方法还不存在。
b.创建新产品代码段。只需要能够编译就可以了。
c.运行测试。肯定会失败。这是一个标准方法，用来确保测试调用了正确的代码，或者错误的代码不会偶然正常工作。这是一个有意义的失败，你也希望它是失败的。
a.想象一下新代码是如何被调用的，然后写一个测试，就好像这段代码已经存在一样。这儿你不会得到只能提示，因为新方法还不存在。
b.创建新产品代码段。只需要能够编译就可以了。
c.运行测试。肯定会失败。这是一个标准方法，用来确保测试调用了正确的代码，或者错误的代码不会偶然正常工作。这是一个有意义的失败，你也希望它是失败的。
3.绿：使测试被任何必要的方法验证通过。
a. 写产品代码并测试通过。注意要简洁。
b.. 有些人认为先验证期望返回值的硬代码，这样测试成功检测会好一些。这一点因人而异。
c. 如果你写的代码如期通过测试，那么你的工作可以告一段落了，不需要再费劲脑汁继续写了。测试是“完成”的客观定义。俗语“够用就好”经常被用来杜绝那些不必要的工作。如果还需要新功能，那就再写一个测试。测试通过后继续。
d. 当测试通过后，也许此时你想要运行所有的测试，以确保一切运转正常。
4.重构：修改代码以清楚你项目中的冗余，在确保所有测试仍然可以通过的情况下修正软件的设计。
d. 清楚由新增功能造成的冗余。
e. 修正设计以优化整体方案。
f. 每次重构后，重新运行所有测试以确保仍被通过。
d. 清楚由新增功能造成的冗余。
e. 修正设计以优化整体方案。
f. 每次重构后，重新运行所有测试以确保仍被通过。
5.重复这一过程。每次重复应该非常短，一个典型的开发时间段内应该包含许多红/绿/重构过程。
测试驱动开发的优点
• 单元测试集合提供持久的每个组件仍正常工作的反馈。
• 单元测试扮演同步更新的文档，保证随时可用。
• 当测试通过，产品代码被重构清楚过冗余时，表明这段代码完成，开发者可以转战下一个测试。
• 测试驱动开发强制严肃的分析和设计，因为开发者在没有正确理解什么是想要的结果和如何测试的情况下不能创建产品代码。
• 软件倾向去更好的设计，也就是说“松耦合和健壮性”，因为开发者可以自由地做设计决定并在任何情况下重构，以保证软件仍在正常工作。
• 测试集扮演一个Bug的回溯安全网：如果发现了一个Bug，开发者应该创建一个测试来看看这个Bug怎么产生的，然后修改产品代码，这样就可以消除Bug而且其他的测试一切正常。在每一个后来的测试运行时，以前的Bug修复都会被验证。
• 减少调试时间。
• 单元测试集合提供持久的每个组件仍正常工作的反馈。
• 单元测试扮演同步更新的文档，保证随时可用。
• 当测试通过，产品代码被重构清楚过冗余时，表明这段代码完成，开发者可以转战下一个测试。
• 测试驱动开发强制严肃的分析和设计，因为开发者在没有正确理解什么是想要的结果和如何测试的情况下不能创建产品代码。
• 软件倾向去更好的设计，也就是说“松耦合和健壮性”，因为开发者可以自由地做设计决定并在任何情况下重构，以保证软件仍在正常工作。
• 测试集扮演一个Bug的回溯安全网：如果发现了一个Bug，开发者应该创建一个测试来看看这个Bug怎么产生的，然后修改产品代码，这样就可以消除Bug而且其他的测试一切正常。在每一个后来的测试运行时，以前的Bug修复都会被验证。
• 减少调试时间。
一个好的单元测试应具备的特点
一个好的单元测试应该具备以下特点：
• 跑得快，跑得快，跑得快。如果测试运行很慢，他们就不会经常被运行。
• 隔离或者模拟环境依赖，比如数据库、文件系统、网络及队列等等。有依赖的测试运行的不会很快，而且一个失败不会给出问题真正所在的有意义反馈。
• 限制范围。如果测试失败，很快就能知道到哪儿查找问题。使用几个断言就可以找出错误的代码所在。在一个测试里面测试一件事情是很重要的。
• 在独立的环境下运行和通过。如果测试需要特殊的环境配置或者失败的不明就里，那么就不是好的单元测试。修改的更简单和可靠一些。测试应该可以在任何机器上运行和通过。“在我机子上可用”的辩解是无用的。
• 经常使用桩和钩子对象。如果被测试的代码调用一个数据库或者文件系统，一定要模仿出那些依赖。一般情况下，可以通过使用接口抽象掉这些依赖。
• 明确表示测试意图。其他的开发者可以看到这个测试并且理解产品代码想达到一个什么目的。
• 跑得快，跑得快，跑得快。如果测试运行很慢，他们就不会经常被运行。
• 隔离或者模拟环境依赖，比如数据库、文件系统、网络及队列等等。有依赖的测试运行的不会很快，而且一个失败不会给出问题真正所在的有意义反馈。
• 限制范围。如果测试失败，很快就能知道到哪儿查找问题。使用几个断言就可以找出错误的代码所在。在一个测试里面测试一件事情是很重要的。
• 在独立的环境下运行和通过。如果测试需要特殊的环境配置或者失败的不明就里，那么就不是好的单元测试。修改的更简单和可靠一些。测试应该可以在任何机器上运行和通过。“在我机子上可用”的辩解是无用的。
• 经常使用桩和钩子对象。如果被测试的代码调用一个数据库或者文件系统，一定要模仿出那些依赖。一般情况下，可以通过使用接口抽象掉这些依赖。
• 明确表示测试意图。其他的开发者可以看到这个测试并且理解产品代码想达到一个什么目的。
结论
测试驱动开发是一种先进的技术，通过使用单元测试可以驱动软件的设计。本文提纲挈领地讲述了这一技术，但市面上已经有了许多关于这个话题的书籍。
测试驱动开发是一种先进的技术，通过使用单元测试可以驱动软件的设计。本文提纲挈领地讲述了这一技术，但市面上已经有了许多关于这个话题的书籍。
你可以使用VSTS在使用或者不使用测试驱动开发的情况下设计单元测试软件。团队应该知道那种方法更适用于他们。
参见James Newkirk的Test-Driven Development in Microsoft .NET一书，微软出版社出版。
参考
• 单元测试概览
• 创建单元测试
• 微软.NET平台上的测试驱动开发：主页
关于作者
Jeffrey Palermo是DataCert公司（应用敏捷开发方法学的一家ISV）的高级软件开发人员。他是奥斯丁.NET用户组的指导者，还是南方Texas的INETA会员经理。Jeffrey拥有MCSD的.NET认证。他的Blog是： http://codebetter.com/blogs/jeffrey.palermo/。
Jeffrey Palermo是DataCert公司（应用敏捷开发方法学的一家ISV）的高级软件开发人员。他是奥斯丁.NET用户组的指导者，还是南方Texas的INETA会员经理。Jeffrey拥有MCSD的.NET认证。他的Blog是： http://codebetter.com/blogs/jeffrey.palermo/。