我知道这个问题:https://stackoverflow.com/questions/428691/how-to-encourage-implementation-of-tdd
在我的团队中,我们编写了大量的单元测试.但是,通常程序员倾向于在编写代码之后编写单元测试.因此,我们首先完成模块功能,然后编写测试.大多数模块的覆盖率约为70%.我已经尝试说服我的技术经理和我的团队成员做纯TDD,其中我们首先编写测试然后编写代码,但是重新获得.我认为首先编写测试可以让我们更好地发现设计.我只是挑剔,特别是当我们的报道很高时？如果这个问题的答案是否定的,那么我该如何与人们谈论采用测试优先的方法.
编辑:我认为编写代码后编写测试更容易.我的团队中的人已经习惯于这样做并反对任何改变.
ckr*_*mer 17
我不知道有很多东西你可以告诉人们让他们相信TDD的价值.您可以引用专家告诉我们的内容以及您自己的个人经历,但如果人们不愿意尝试,那么与他们分享这些信息的机会很低.
我对TDD的体验基本上听起来像是一个非常好的主意,但它从来没有按照预期的方式实现.然后有一天,我再次尝试了一项新任务,最终找到了一个比我想象的更简单的问题解决方案,完全归功于我使用过TDD这一事实.我认为,当开发人员拥有这种体验时,它会改变他们看待事物的方式,并使他们更愿意在其他情况下尝试它.
挑战是能够向其他开发人员证明这一点.你可以做到这一点的一种方法是使用像Roy Osherove 这样的TDD Kata (他在他的TDD硕士课程中使用它).它专门用于演示以小步骤工作的价值,仅实现使每个测试通过所需的代码.这可能会向人们展示这个过程是如何运作的,并让他们尝试更舒服.
还有一个编码练习,我听说你给两个团队/开发团队一个相当简单的任务,并要求其中一个团队使用TDD,并确保他们遵循"最简单的可能工作"的规则,同时另一支球队做了他们想要的事情.然后,一旦完成,您就可以让团队切换任务,但是抛弃每个团队编写的代码,只留下测试.然后团队应该重新创建任务的代码.通常,您会发现继承TDD代码的团队可以更轻松地完成此操作.
尽管如此,我认为你个人最好的事情就是尽可能多地开始做TDD.这有可能为您提供一些非常具体的参考资料,说明在当前项目的背景下TDD在何处以及如何被证明是有益的.特别是如果您进行代码审查,您的同行可能会注意到您编写的代码TDD比没有TDD编写的代码更简洁,更易于维护.您的QA团队也可能会注意到代码质量的差异,这是您听到很多关于转向TDD的公司的事情之一.
一对夫妇的建议.您的实用性可能有所不同: