我们运行一个项目，希望通过测试驱动开发来解决这个问题。我想到了启动项目时出现的一些问题。一个问题是：谁应该为一项功能编写单元测试？单元测试应该由功能实现程序员编写吗？还是应该由另一个程序员编写单元测试，由他定义方法应该做什么，并且功能实现程序员在测试运行之前实现该方法？
如果我以正确的方式理解 TDD 的概念，实现特性的程序员必须自己编写测试，因为 TDD 是具有小迭代的过程。那么让其他程序员编写测试会太复杂吗？
你打算说什么？ TDD 中的测试应该由程序员自己编写还是应该由其他程序员编写描述方法可以做什么的测试？
【问题讨论】：
标签： unit-testing tdd
在 TDD 中，开发人员首先编写失败的单元测试，然后修复生产代码以使测试通过。这个想法是，更改是在非常小的步骤中进行的 - 所以你编写一个调用不存在的方法的测试，然后通过添加一个空方法来修复测试，然后在测试中添加一些关于该方法的断言所以它再次失败，然后你实现该方法的第一次切割，等等。因为这些步骤太小，让一个单独的人编写测试是不切实际的。另一方面，我建议配对，这样您就可以获得一些额外的眼球，确保代码有意义。
我认为有可能让另一个人/团队/甚至客户（当您使用 Fitness 等工具时）编写验收测试，在更高级别测试整个功能。
【讨论】：
TDD 的好处之一是反馈周期快。让另一个开发人员编写测试会大大减慢这个过程。应该由同一个开发者编写。
【讨论】：
这可以通过两种方式完成，您可以自己编写单元测试，也可以采用乒乓方式，轮流与其他开发人员一起编写单元测试并编写实现（如果您结对的话）。正确的解决方案是适合您和您的团队的解决方案。我更喜欢自己编写测试，但我知道其他人也很幸运地使用了乒乓方法。
【讨论】：
单元测试和验收测试是两件不同的事情，两者都可以（并且应该）在 TDD 中完成。单元测试是从开发人员的角度编写的，以确保代码按照她的期望进行。验收测试是从客户的角度编写的，以确保代码满足适当的需求。由其他人编写验收测试可能很有意义（通常因为它需要稍微不同的思维方式和领域知识，并且因为它们可以并行完成）但单元测试应该由开发人员编写。
TDD 还说你不应该编写任何代码，除非是为了响应失败的测试，因此不得不等待其他人编写单元测试似乎效率很低。
【讨论】：
应该在编码之前编写单元测试并测试单元是否满足要求，因此实现代码的开发人员也可以编写单元测试。
【讨论】：
我认为您需要将自动化单元测试与测试驱动开发分开。 （恕我直言，在这里做出重要区分的不只是您）。
AUT 强烈建议，TDD 要求先编写测试。
TDD 还使测试成为编写代码过程的重要组成部分。 TDD 与其说是一种质量保证方法，不如说是一种思考代码的方式——因此单独的职责将违反 TDD 的理念。它们也是不切实际的——新测试/新代码周期非常小，通常只需几分钟。在我的理解中，Test Driven Design 会是更好的描述。
AUT 可以安装在现有的代码库上（尽管通常很糟糕，具体取决于代码库的大小和结构）。单独的职责在这里可能有一些优势。尽管如此，AUT 还是对设计施加了一些压力 - 因此分离将在 谁键入代码 级别进行。
区别：我坦率地承认我不喜欢 TDD 的想法。它可能适用于某种类型的编码器，适用于某些应用程序，在某些市场中——但我迄今为止看到的所有示例、演示和演练都让我不寒而栗。 OTOH，我认为 AUT 是一种有价值的质量保证工具。 一个有价值的工具。
【讨论】：
我有点困惑。
您说您想使用 TDD，并且您似乎正确理解程序员编写测试，然后同一个程序员编写实现并在编写测试后的几秒钟/几分钟内完成。这是 TDD 定义的一部分。 （顺便说一句，在练习结对编程时，'同一个程序员'也意味着'结对中的另一个程序员'）。
如果你想做一些不同的事情，那就去做吧，并在博客或文章中写下你的经历。
你不应该做的是说你做不同的是TDD。
'同一个程序员'写实现，并在测试后很快写的原因是为了快速反馈，发现如何编写好的测试，如何设计软件以及如何编写好的实现。
【讨论】：
根据 Justin 的回答，执行开发人员编写测试不仅可以，而且是事实上的标准。理论上，另一个程序员编写测试也是可以接受的。我曾玩弄过“测试”程序员支持“功能”开发人员的想法，但我没有遇到过示例。
如果我为一个对象编写测试，除了我期望的输入和输出之外，我还必须知道它公开的接口。换句话说，必须在开发开始之前决定要测试的类和方法。在十二年的时间里，我只有一次在一家在开发开始之前就实现了这种设计粒度的商店工作过。我不确定你的经历是什么，但对我来说似乎不是很敏捷。
【讨论】：