学习TDD：TDD的好处
|
?TDD的全称是Test Driver Development，测试驱动开发。就是开发要以测试为驱动。编码之前，测试先行。代码都没有，我如何测试，我连要测的对象都没有啊？这好像是个问题。 ? ?
? 首先站在客户方代码的立场，可以获得更好的api。 前期投入大，后期能大幅缩短开销，将问题发现在最源头 ? ? 提供明确的目标: TDD所带来的好处是否被过度的夸大？? 当需要进行测试时，我信守下面的经验主义的做法：
TDD( 测试驱动开发) Overview 第一篇技术博客，希望有人支持，您的关注是我的动力... 本文主要是基于本人的开发经验，概叙一下TDD，也就是测试驱动开发。我比较喜欢用问题方式来写，语言水平有限 希望读者看得懂且有帮助 TDD这个东西 你一般用了之后会上瘾:) 它可能改变你以后的编程习惯 什么是TDD 故名思意就是用测试的方法驱动开发。简单说就是先写测试代码，再写开发代码，和传统的方式是反的。 为什么要用TDD 用TDD的方法可以使代码干净（代码重构的结果），测试覆盖率高（先写测试的结果），软件做集成测试的时候一般问题会比较少。 而且你敢改人家的代码，看到有fail的test case 证明你有改错人家的东西，看到所有的test case都过了的话，你也很有信心说，我没有改错，或程序不会因为我的改动而挂掉。 什么时候TDD TDD是在Unit Test,? 也就是单元测试时用的方法。 什么地方TDD 我觉得写任何代码都可以用TDD吧 怎么做TDD（关键5步）
而外还有一些步骤也是可以加入的，比方
TDD的好处，和不足的地方 好处
缺点
怎么学习TDD最好 我觉得最好且最快的方式就是 XP中提到的结对编程，一个有TDD经验的坐在"后面"，指导另一个不大熟悉的人，两人一起来完成一个类或模块的功能 几个关键点
后面的文章我准备用VS2008来举简单的例子，还有一些测试的模式，测试的辅助工具... 关于TDD的观点：质量是反复思考的结果，仅靠解决Bug无法获得 “通过单元测试可以改善代码质量”这一观点已经得到广泛认可。培训师、顾问兼咨询师Michael Feathers在最近的帖子中对其提出了质疑。他谈及单元测试、集成测试、TDD和净室软件开发（Clean Room Software Development），认为代码质量是反复思考的结果，仅靠解决bug无法获得。M3P的独立咨询师Steve Freeman进一步阐述了Michael的观点，从“认知方面对TDD进行了分析”，并解释了TDD的好处从何而来。 Michael认为，利用测试找Bug来改善质量的想法是有不足之处的： 对于单元测试，最常见的理论就是“通过解决测试找到的bug，软件的质量得以提升”。乍听起来，好象没错儿。测试有通过或失败两种结果，一旦失败，我们就知道肯定是有什么地方出了问题，就要修复它。假如你赞同这个说法，你就会预期在做集成测试时发现更少的集成错误，在做单元测试时也是一样。这个观点貌似挺好，不过它是错误的。能够证明这一点的最佳方法就是：将单元测试与另一种提高质量的方法相比较，而且这种方法有着很好的度量效果。 为了证明他的观点，Michael提到净室软件开发（Clean Room Software Development），这是一种在上个世纪八十年代曾被使用的开发方法。根据Michael所述，净室方法不包括任何单元测试过程： 净室方法背后的观念，就是要通过更严格的开发纪律来提高质量；在净室中，你要为每一小短代码写逻辑断言；在代码复查时，你还要证明代码的功能和你写的断言完全符合，功能不多也不少。这种方法非常严格，甚至比我所说还要极端，因为净室方法的另一个宗旨是：不能有单元测试。一个都没有。毫无必要。代码开发完成之后，只要被复查过就被认为是完全正确的。唯一的测试就是在功能层面的随机测试。 使用净室方法的结果很有趣：不经任何单元测试，代码质量也提高了。净室方法和TDD方法的相似之处在于：迫使开发人员不断复查、重构并改进他的代码。Michael的结论就是： 我认为，我们不能机械地看待测试。单元测试并不能在“单元”这个层次上通过抓到错误来改进质量。而且，集成测试也不能在“集成”这个层次上通过抓到错误来提高质量。实际上背后的道理难以言说。质量是反复思考的结果——严谨的反复思考。这就是关键。强化纪律的技术一定会提高质量。 从Michael的帖子出发，M3P的独立咨询师Steve Freeman进一步阐述了这个观点，并谈到“对TDD在认知上的分析”。开发人员的某些决定会影响他们的代码： 事实证明，人们并没有真正花时间从各种可行的方案中进行权衡，而是使用了“首先契合（first-fit）”的方法，即将已知的解决方案按序排列，然后选择第一个看上去最好的方案。所有这些都是在潜意识下发生的。在这之后，我们迟钝的理性思维才会想办法证明这个已成事实的决定——我们甚至都不知道这些是如何发生的。 关键在于不要直接采纳第一个在我们脑海里出现的解决方案，而是要评估不同的可选方案，这就是Steve认为TDD有益的原因： 测试驱动开发打破“首先契合”这种模式匹配，从而发挥了（或应该发挥）作用。通过TDD，我们不再强制用脑海中出现的第一方案来解决问题。我们也不得不远离自己的“安全地带（comfort zone）”来考虑真正需要实现的需求。更重要的是，从“写一个测试开始”迫使我们首先去想真正需要的是什么（要测试什么），然后再用我们专家般敏锐的大脑来得出解决方案。 Steve举了一个例子来证明他的观点： 最有力的证据就是Arlo Belshee所在的小组，他们实现了无序结对编程（Promiscuous Pairing）。他们从经验中发现：相对于成员自己决定结对时间，强制他们每隔几个小时就切换结对，这样的生产率最高。他们认为，这样可以保持每个人处于“初学者”的心态，也就可以像“初学者”那样思考。 争论TDD版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明 咨询的过程中，经常会与人讨论TDD。初时，我会很耐心的跟人解释TDD的种种好处，试图让他们能够皈依TDD，结果总不尽如人意，争论者总是可以抛出一些新的观点，逼迫着我重新认识TDD，甚至最低落时，我会怀疑TDD是不是真的有效。 ? 历史上的今天：
做好该做的事 2006-05-16
Java基本功——Reference 2005-05-16
引用地址：
? 实际经验证明：TDD可以提高软件质量在Empirical Software Engineering杂志上首次发表的一篇研究报告声称：“看来TDD可以应用在多个领域中，并显著降低软件的缺陷密度，同时也不会明显降低开发团队的工作效率。”研究对比了4个在微软和IBM执行的项目，这些项目使用了TDD方式开发，并与没有使用TDD开发的类似项目进行了对比。 研究报告的作者包括：来自微软的Nachi Nagappan和Thirumalesh Bhat 、IBM的E. Michael Maximilien，以及北卡罗来纳大学的Laurie Williams，并发布在Empirical Software Engineering杂志的第13卷第3期上。读者也可以在微软研究院的Empirical Software Engineering Group中找到该报告。 报告中研究的4个案例，1个来自IBM，3个来自微软。每个案例研究都对比了开发同一个产品的两个团队，他们使用同样的开发语言和技术，处于同一级别的管理之下，唯一不同之处在于：一个团队使用TDD，另一个不用。在开发过程中，这些团队都不知道自己处于研究之下。IBM案例中的团队在开发设备驱动程序，微软的团队在开发Windows、MSN和Visual Studio的相关应用。 报告中讲述了团队使用的TDD实践，包括分钟级别的工作流程（minute-to-minute workflow）和任务级别的工作流程（task-level workflow）。 分钟级别的工作流程如下：
任务级别的工作流程是这样子的：
缺陷密度是通过每千行代码的缺陷数目来衡量的。相较于不使用TDD的项目而言，这四个产品在发布前的缺陷密度降低了40%到90%。从团队管理层的主观报告看来，在开发的初始阶段，使用TDD的团队要多花15%到35%的时间；不过团队都同意一点：这个时间被减少的产品维护时间抵消掉了。 报告中的结果可以与Maria Siniaalto在2006年发布的一篇文章相对比。该文章中试图复审并总结其他13项有关TDD的研究，这些研究包括在纯商业背景、半商业背景和学院背景中进行的研究。在文章的结论中，作者写道： 基于这些现有研究的发现，可以得出结论：TDD看来可以提升软件质量，特别是在纯商业背景中。对于半商业背景或学院环境中的研究来说，结论不是那么明显，可这些研究没有提到任何软件质量的降低。TDD给工作效率带来的效果不是十分明显，而且结果会根据研究的环境发生变化。然而，有证据证明：TDD不一定会降低开发人员的工作效率，或是增加项目的交付时间。某些情况下，TDD会带来显著的工作效率提升；同时，在提到的13个案例研究中，只有两个案例指出工作效率降低了，不过这两个案例同时指明质量的提升。 您使用TDD有哪些经验？见到质量的提升了么？对于开发人员的工作效率和开发时间，您看到了哪些影响？请在文后留下您的评论，分享您的经验。 查看英文原文：Empirical Studies Show Test Driven Development Improves Quality 译者 郑柯 曾任职《程序员》杂志副主编，《项目管理修炼之道》译者。 9 条回复关注此讨论 回复 ?
TDD 能提升质量在意料之中，那么效率呢？发表人 Zhang Charlie 发表于
04/03/2009 03:47 <!-- ww:date name="%{top.creationDate}" format="%{#request['postDateTimeFormat']}" /> -->
?
Re: TDD 能提升质量在意料之中，那么效率呢？发表人 .H.Fu James 发表于
05/03/2009 10:42 <!-- ww:date name="%{top.creationDate}" format="%{#request['postDateTimeFormat']}" /> -->
?
Re: TDD 能提升质量在意料之中，那么效率呢？发表人 Zhang Charlie 发表于
05/03/2009 12:15 <!-- ww:date name="%{top.creationDate}" format="%{#request['postDateTimeFormat']}" /> -->
?
Re: TDD 能提升质量在意料之中，那么效率呢？发表人 guan jayden 发表于
05/03/2009 11:21 <!-- ww:date name="%{top.creationDate}" format="%{#request['postDateTimeFormat']}" /> -->
?
Re: 请问你有没有在实际项目中使用过TDD？发表人 Zhang Charlie 发表于
05/03/2009 11:59 <!-- ww:date name="%{top.creationDate}" format="%{#request['postDateTimeFormat']}" /> -->
?
Re: TDD 能提升质量在意料之中，那么效率呢？发表人 He Yiding 发表于
06/03/2009 11:27 <!-- ww:date name="%{top.creationDate}" format="%{#request['postDateTimeFormat']}" /> -->
?
Re: 你好像从没看过 TDD 相关的文章和书发表人 Zhang Charlie 发表于
06/03/2009 11:50 <!-- ww:date name="%{top.creationDate}" format="%{#request['postDateTimeFormat']}" /> -->
?
Re: TDD 能提升质量在意料之中，那么效率呢？发表人 Lee Vincent 发表于
27/08/2009 05:10 <!-- ww:date name="%{top.creationDate}" format="%{#request['postDateTimeFormat']}" /> -->
?
我决定TDD的好处有两个 发表人 一 刀 发表于
07/03/2009 01:18 <!-- ww:date name="%{top.creationDate}" format="%{#request['postDateTimeFormat']}" /> -->
?
按日期倒序排列
（编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
评论
1.下手之前更清楚自己要干什么
2.在重构的过程中有了一层保险,不至于改了代码,引发了其他地方的bug
-------------
深有同感！一个团队里有工作一两年的新手是正常的，比较恐怖的是，他们不知道正确的方向在哪。当他们在工作年限上成为老手，而编程功力却停留在一两年的新手水平时，团队在他们在支配下，很可能被带入万劫不复的境地。
别人告诉你怎么做可行，你不信
别人说你去试试看，你不试
那你想怎样？
想找个人帮你把项目带了算了？帮不帮你领工资？