如何应对那些破坏人们的TDD？

就个人而言,我更喜欢单元测试,并将其编写为"良好"的覆盖范围.(假设我尽可能努力地写出好的测试;)

像往常一段时间后,有些人需要在代码中添加一些功能(向类中添加方法等).他没有打破那些书面单元测试,但拒绝写额外的(这将涵盖他编写的代码的其他功能).这导致了tdd过程中的一个大漏洞(更糟糕的是可能是一个破窗口效应)

我能做些什么来让他写下那些测试？你是如何与这些人打交道的？

请记住,TDD主要不是为了产生良好的单元测试覆盖率; 它是关于激励优秀设计,关于确保您编写的代码符合您的期望,以及提供高质量测试的第三方.

当另一个程序员在没有编写测试的情况下扩展课程时,他们错过了这些好处,你应该对他们感到怜悯.但是当你工作的时候,你将继续以最好的方式工作(首先测试),因为你知道你得到的解耦代码对于消费者来说很容易,并且你的代码符合你的期望.

对您来说最大的痛苦是您必须要小心重构的内容:如果您正在重构正在测试的代码,您可以快速进行,并且设计将快速安全地改进.如果要重构未经过测试的代码,则应该非常谨慎地重构它(可能只使用可靠的自动化工具)或添加测试.

最后,您将继续受益于您对TDD的使用,因为您可以更快地生成更清晰,更正确的代码,同时您的TDD受损同事将受到影响.

不要将此视为对抗!你问的是如何强迫同事做某事他/她显然没有任何好处.你无法让某人使用TDD - 正如你自己已经看到的那样.开发人员接受TDD的唯一方法就是当其他人帮助他们达到"啊哈!"时.时刻.作为一个同事尊重他人并通过你的行为表明他/她并积极地想要帮助他/她克服精神上的困难.

配对编程.有两个人在做某事,程序员不太可能像这样做捷径.