测试驱动开发和配对编程

Question

我在一个团队,我试图说服我的队友采用TDD(因为我已经看到它在我以前的团队工作,设置类似).另外,我个人认为,至少在开始时,如果TDD和结对编程都是一起完成的话,这确实有帮助.这样,两个缺乏经验的(在TDD中)开发人员可以互相帮助,讨论要编写哪种测试并取得良好进展.

另一方面,我的经理认为,如果我们一次在团队中引入两个新的开发实践,那么两者都很可能会失败.所以,他希望保守一点并介绍任何一个.

我如何让他相信这两者都是互补的而不是正交的.或者我错了？

Answer 1

我不确定是否有更多的人不知道他们在TDD中做了什么会有所帮助.它会很快进入你们两个人的谷歌搜索主题,或者你们俩都在争论TDD究竟是什么/不是什么.

我认为你最好让团队中的某个人成为某种技术的传播者(有人去读TDD,有人去阅读对编程)并让这些人推广和试验这些东西.是的,两者都可以同时发生,但不必在整个项目团队中使用.你可以让你的团队中的一小部分人进行编程,然后报告他们的经历.

Answer 2

在学习新练习尤其是TDD时,对编程是有效的

所以,你可以同时妥协.以增长的方式以敏捷的方式做到这一点.首先进行结对编程.这两者更容易.配对编程后的所有练习将变得更容易学习,并且将更快地以更高的一致性被团队采用.结对编程是第一个(如果不是第一个应该采用的工程实践)之一.确保它有效地完成.以下是如何进行结对编程的说明.

配对编程是开发团队在开发软件时可以使用的最有效的实践之一.两位开发人员使用一台计算机和键盘积极开发故事卡.管理人员担心使用配对编程会使编程成本翻倍.乍一看,为什么他们会认为 - 毕竟 - 两个开发人员被要求在同一个任务上一起工作是可以理解的.然而,在实践中,使用这种开发技术的敏捷团队发现,初始开发的成本略有增加(根据犹他大学的研究,这一比例为15%)远远超过了缺陷的减少,更短,更便宜的测试循环和减少对生产支持的需求.

虽然让程序员配对并协同工作可能会提高生产率似乎违反直觉,但这种技术真正起作用的原因有很多(想想古老的说法,"两个人比一个人好.")这就是为什么:

• 提高质量 - 配对鼓励代码审查.键入时会发现许多错误.配对编程意味着由两个致力于代码质量的人员进行连续的代码审查,并且他们一直在共同识别和修复错误.犹他大学进行的一项研究发现,代码中编码的代码平均减少了15%.
• 花费更少的时间"坚持" - 编程很难.开发人员往往很难找到解决方案并花费更多时间而不是"卡住".让合作伙伴集体讨论想法并同意在必要时寻求帮助可以减少因试图找到解决方案而花费的非生产时间.
• 减少分心时间 - 开发人员不太可能花时间打个人电话或网上冲浪,或者在与合作伙伴合作时发送电子邮件假期.
• 两个视角应用于问题 - 不同的经验水平,不同的问题解决方式,不同的辅助技能都增加了更快地解决问题的机会.犹他大学完成的这项研究还确定了成对编写的软件更好的整体设计和更短的代码长度.
• 减少对未知的恐惧 - 与其他开发人员配对时,解决问题或尝试处理新技术比单独工作时更容易.随着时间的推移,他们还可以更好地理解整个应用程序.最后,项目最终会有多人通过配对了解系统的每个部分.
• 不太可能构建范围 - 开发人员通常愿意添加未在要求中解决的功能.在使用一对时,第二个开发人员更有可能让他/她的伴侣完成任务.
• 改进的团队动力 - 由于采用了配对方法,人们可以学会一起工作.他们更频繁地交谈并体验更好的信息流.团队动力因此得到改善.事实上,我们发现最好的团队建设经验是合作生产客户所兴奋的软件.每个人都喜欢成为一个成功团队的一员.
• 消除知识孤岛 - 领域知识,代码或实践知识通过团队和开发人员在轮换的基础上快速传播.

一旦团队配对很舒服,那就采取TDD.下面是一个描述:

测试驱动开发(TDD)是一种软件开发工程实践,包括短期开发,首先编写覆盖所需改进或新功能的新测试用例,然后实现通过测试所需的生产代码,最后软件经过重构以适应变化.在实际开发之前测试的可用性确保在任何变化之后快速反馈.从业者强调,测试驱动开发是一种设计软件的方法,而不仅仅是一种测试方法.测试驱动开发是一种强大的实践,是减少生命周期后期发现的缺陷的主要因素.强烈建议新团队与体验TDD从业者配对或以其他方式接受TDD辅导

测试驱动开发要求在代码本身的每个方面之前编写定义代码要求的自动化单元测试.这些测试包含真或假的断言.运行测试可以在代码发展和重构时快速确认正确的行为.基于xUnit概念的测试框架提供了一种用于创建和运行多组自动化测试用例的机制.测试驱动的开发周期:以下序列基于"按示例进行测试驱动开发"一书,许多人认为这是现代形式的概念的规范源文本.

1. 写一个测试.在测试驱动开发中,每个新故事卡都以编写测试开始.此测试将失败,因为它是在功能实现之前编写的.为了编写测试,开发人员必须清楚地理解该功能的规范和要求.这可以通过具有验收标准的故事卡来完成,以指定何时满足要求.这也可能意味着对现有测试进行不变或修改.在编写代码之后,这是测试驱动开发与编写单元测试的区别特征:它使开发人员在编写代码之前关注需求,这是一个微妙但重要的区别.
2. 运行所有测试并查看新测试是否失败.这验证了测试工具正常工作,并且新测试不会错误地通过而不需要任何新代码.新测试也应该因预期的原因而失败.这个步骤测试了测试本身,这是消极的:它排除了新测试总是通过的可能性,因此毫无价值.
3. 写一些代码.下一步是编写一些会导致测试通过的代码.在这个阶段编写的新代码并不完美,例如,可能会以不雅的方式通过测试.这是可以接受的,因为后面的步骤会改进并磨练它.重要的是,所编写的代码仅用于通过测试; 在任何阶段都不应预测和"允许"进一步(因此未经测试)功能.
4. 运行自动化测试并看到它们成功.如果现在所有测试用例都通过,程序员可以确信代码满足所有测试要求.这是开始循环最后一步的好点.
5. 重构代码.现在可以根据需要清理代码.通过重新运行测试用例,开发人员可以确信重构不会破坏任何现有功能.删除重复的概念是任何软件设计的重要方面.但是,在这种情况下,它还适用于删除测试代码和生产代码之间的任何重复 - 例如,在两者中重复的幻数或字符串,以便在步骤3中使测试通过.

重复

从另一个新测试开始,然后重复该循环以推进该功能.步骤的大小可以与开发者喜欢的一样小,或者如果他/她感觉更自信则会变大.如果为满足测试而编写的代码不能很快地执行此操作,那么步长可能太大,并且可能应该使用较小的可测试步骤.使用外部库时,重要的是不要增加小到仅仅有效地测试库本身的增量,除非有理由相信库有错误或功能不完整以满足所有需求.正在编写的主程序.

开发风格使用测试驱动开发有很多方面,例如"保持简单,愚蠢"(KISS)和"你不需要它"(YAGNI)的原则.通过专注于仅编写通过测试所需的代码,设计可以比通常通过其他方法实现的更清晰和更清晰.测试驱动的开发要求程序员首先使测试用例失败.我们的想法是确保测试真正起作用并且可以发现错误.一旦显示,将开始正常循环.这被称为"测试驱动的开发Mantra",被称为红色/绿色/重构,其中红色意味着失败,绿色通过.测试驱动开发不断重复添加失败,传递和重构的测试用例的步骤.在每个阶段接收预期的测试结果可以加强程序员对代码的心理模型,增强信心并提高生产率

Answer 3

建议他们在TDD上阅读这些书:

迈克尔羽毛的工作有效地与遗留代码
Kent Beck的经典测试驱动开发-以身作则,
杰拉德·梅萨罗斯的xUnit测试模式-重构测试代码
测试驱动开发的Microsoft .NET

或者这些网站在结对编程中:

结对编程(维基百科)
Corey Haines结
对编程发光