在TDD中，测试是否应由实施被测功能的人员编写？

Question

我们运行一个项目，我们希望通过测试驱动开发来解决这个问题。我想到了启动项目时出现的一些问题。一个问题是：谁应该为功能编写单元测试？单元测试应该由功能实现的程序员编写吗？或者，单元测试应该由另一个程序员编写，该程序员定义了一个方法应该做什么，并且特征实现程序员在测试运行之前实现该方法？ 如果我以正确的方式理解TDD的概念，那么特征实现程序员必须自己编写测试，因为TDD是具有小型迭代的过程。因此，让另一个程序员编写测试会太复杂了吗？ 你打算说什么？ TDD中的测试应该由程序员自己编写，还是应该由其他程序员编写描述方法可以执行的测试？

Answer 1

在TDD中，开发人员首先编写失败的单元测试，然后修复生产代码以使测试通过。我们的想法是更改是以非常小的步骤进行的 - 所以你编写一个调用不存在的方法的测试，然后通过添加一个空方法修复测试，然后在测试中添加一些关于方法的断言所以它再次失败，然后你实现方法的第一个切割，等等。因为这些步骤太小，让一个单独的人写测试是不切实际的。另一方面，我会建议配对，这样你就可以获得一些额外的眼球，确保代码有意义。

我认为有可能让另一个人/团队/甚至是客户（当你使用像Fitness这样的工具时）来编写验收测试，以便在更高的层次上测试整个功能。

Answer 2

TDD的一个好处是快速反馈周期。让另一个开发人员编写测试会使进程过于缓慢。同一个开发人员应该同时写两个。

Answer 3

它可以通过两种方式完成，您可以自己编写单元测试，或者选择乒乓方法，然后轮流与另一位开发人员编写单元测试并编写实现（如果您正在配对）。正确的解决方案是适合您和您的团队的解决方案。我更喜欢自己编写测试，但我也知道其他人也对乒乓球方法感到满意。

Answer 4

单元测试和验收测试是两个不同的事情，两者都可以（并且应该）在TDD中完成。单元测试是从开发人员的角度编写的，以确保代码正在执行她期望的操作。验收测试是从客户的角度编写的，以确保代码满足适当的需求。接受测试由其他人编写很有意义（通常因为它需要稍微不同的思维模式和领域知识，并且因为它们可以并行完成），但单元测试应该由开发人员编写。 / p> TDD还说你不应该写任何代码，除非是为了响应测试失败，所以不得不等待别人写单元测试似乎效率很低。

Answer 5

单元测试应该在编码和测试单元满足要求之前编写，因此实现代码的开发人员也应该编写单元测试。

Answer 6

我认为您需要将自动单元测试与测试驱动开发分开。 （恕我直言，不仅仅是你应该在这里做出重要的区别）。

AUT强烈建议，TDD要求首先编写测试。

此外，TDD使测试成为编写代码过程的重要部分。 TDD不是一种质量保证方法，而是一种思考代码的方法 - 所以单独的责任将违背TDD的理念。它们也是不切实际的 - 新的测试/新代码周期非常小，通常只需几分钟。根据我的理解，测试驱动设计 将是一个更好的描述。

AUT可以安装在现有代码库上（尽管通常很糟糕，取决于代码库的大小和结构）。单独的责任可能在这里有一些优势。尽管如此，AUT对设计施加了一些压力 - 因此分离将在处理代码级别。

---

区别：我坦率地承认我不喜欢TDD的想法。对于某些类型的编码器，某些应用程序，某些市场可能会运行良好 - 但我所看到的所有示例，演示和演练现在让我不寒而栗。 OTOH，我认为AUT是质量保证的宝贵工具。 一个有价值的工具。

Answer 7

我在这里有点困惑。

你说你想要使用TDD并且你似乎正确地理解程序员编写测试，然后同一个程序员编写实现并在编写测试后的几秒/几分钟内完成。这是TDD定义的一部分。 （顺便说一句，“同一个程序员”在执行结对编程时也意味着“对中的其他程序员”）。

如果你想做一些不同的事情，那就去做吧，在博客或文章中写下你的经历。

你不应该做的就是说你做的不同就是TDD。

'同一个程序员'编写实现的原因，并在测试后很快编写它是为了快速反馈，发现如何编写好的测试，如何设计软件以及如何编写好的实现。

请参阅The Three Rules Of Tdd。

Answer 8

Per Justin的回答，不仅是实施开发人员编写测试还是好的，它是事实上的标准。从理论上讲，另一个程序员也可以编写测试。我已经玩弄了“测试”程序员支持“功能”开发人员的想法，但我没有遇到过例子。

如果我为对象编写测试，除了我期望的输入和输出之外，我还必须知道它暴露的接口。换句话说，必须在开发之前决定所测试的类和方法。在十二年的时间里，我只有一次在一家商店工作，在开发之前就已经实现了那种粒度的设计。我不确定你的经历是什么，但对我来说似乎并不敏感。