我的一个朋友正在解释他们如何在他的工作场所与TDD进行乒乓球配对,他说他们采取“对抗”的方式.也就是说,当测试编写人员将键盘交给实现者时,实现者试图做最简单的(有时是错误的)来使测试通过.

例如,如果他们正在测试GetName()方法并且测试检查“Sally”,则GetName方法的实现将只是：

public string GetName(){
    return "Sally";
}

当然,这将通过测试(天真地).

他解释说,这有助于消除检查特定固定值的天真测试,而不是测试组件的实际行为或预期状态.它还有助于推动更多测试的创建,最终实现更好的设计和更少的错误.

这听起来不错,但是在与他的短暂会谈中,似乎需要花费更长的时间来完成一轮测试而不是其他方式,我并不觉得获得了很多额外的价值.

你是否使用这种方法,如果是这样,你看到它得到了回报吗？

最佳答案 它基于团队的个性.每个团队的个性都是其成员的总和.你必须要小心,不要以优势的方式练习被动式攻击性实施.一些开发人员对这样的实现感到沮丧

return "Sally";

这种挫败感会导致团队失败.我是沮丧的人之一,并没有看到它的回报.我认为更好的方法是更多的口头交流,就如何更好地实施测试提出建议.