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

例如，如果他们正在测试GetName()方法，并且测试检查" Sally"，则GetName方法的实现将简单地是：

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

当然，这将通过测试(天真)。

他解释说，这有助于消除检查特定罐头值的幼稚测试，而不是测试组件的实际行为或者预期状态。它还有助于推动创建更多的测试，并最终改善设计并减少错误。

听起来不错，但在与他的简短会谈中，通过单轮测试似乎要花更长的时间，而且我不觉得自己获得了很多额外的价值。

我们是否使用了这种方法，如果可以，我们是否看到了这种回报？

解决方案

我已经使用了这种方法。它不适用于所有配对。有些人是天生的抵抗者，不会给自己一个诚实的机会。但是，它可以正确执行TDD和XP。我们想尝试将功能缓慢添加到代码库中。我们不想编写庞大的整体测试，而这需要大量代码才能满足。我们需要一堆简单的测试。我们还需要确保定期在键盘对之间来回传递键盘，以使两个键盘对都啮合。通过对抗配对，我们可以同时进行。简单的测试导致简单的实现，代码构建缓慢，整个过程都涉及到两个人。

它基于团队的个性。每个团队的个性都是其成员之和。我们必须注意不要练习优越的氛围进行被动进取的实现。一些开发人员对诸如以下的实现感到沮丧

return "Sally";

这种挫败感将导致团队失败。我当时很沮丧，没有看到回报。我认为更好的方法是更多的口头交流，就如何更好地实施测试提出建议。

我有时会喜欢它，但不要一直使用那种风格。有时可以很好地改变步伐。我认为我不想一直使用这种样式。

我发现它对于初学者来说是一个有用的工具，可以介绍测试如何驱动实现。

这可能非常有效。

它迫使我们更多地考虑必须编写哪种测试才能使其他程序员编写所需的正确功能。

我们可以频繁地通过键盘来构建代码段

这可能很累并且很耗时，但是我发现它很少见，我不得不返回并修复这样编写的任何代码中的错误