从敏捷宣言中，敏捷价值观：
个人和流程与工具之间的互动，
通过综合文档工作软件，
合同谈判中的客户合作，
响应遵循计划的变更
TDD是否制定了计划并几乎构成了合同谈判？
“你想要什么功能？” “1,2,3” 开发人员为1,2,3 - >写入测试;团队提供代码 “这是1,2,3给我们钱”
它也是一种全面的文档形式，也是一个过程。一旦测试被写入，个人和互动就不再那么重要，因为“真相的来源”不再是人，而是在代码中解决。
只是想知道他们如何相互配合，如果他们反对或者他们一起工作？
答案 0 :(得分：2)
TDD更像是个人贡献者的实践，而不是流程。这里的测试通常是指单元测试，它是开发工作的一部分，而不是性能，功能和集成测试等综合测试服务。
在某些情况下，TDD应该帮助个人贡献者真正考虑需求和实施（响应变化并提出工作软件）。我个人并不采用这种做法，但它是一种敏捷的做法，可以由一个贡献者采用。不要将它与更高级别的测试和相关文档混淆。答案 1 :(得分：1)
然而，TDD并没有制定计划
不。 TDD并不意味着＆＃34;预先编写测试＆＃34;它意味着在编写代码之前编写测试＆＃34;。整个＆＃34;尽可能多地做你需要的事情而不是更多＆＃34;发挥作用。在编写任何代码之前，您不应该为所有功能编写测试，只是您当前所使用的功能。然后（取决于测试级别），该功能的一小部分将需要测试现在。
它也是一种全面的文档形式，也是一个过程
它还有助于使用工作软件。
工作软件 over 综合文档，
结束，而不是。如果你能两者兼顾，那就太好了。
测试是个人和互动不再重要，因为真实的来源＆＃34;已经不再是人了，而是在代码中解决了。
它做什么的oracle始终是代码。 应该做什么的神谕始终是人。 TDD做得好也有助于沟通。
为什么有些人似乎对这个问题感到生气？
这个问题很快就出现了问题。你正在扭曲宣言，使它听起来像任何有助于后者的事情是＆＃34;坏＆＃34;而且你正在扭曲TDD的定义，使其成为一个包罗万象的，完全是前沿的过程。这两者都不是真的。
个人和流程与工具之间的互动，
BDD是帮助dev / BA /利益相关者级别的互动的绝佳工具。 TDD（xUnit和alikes）是帮助开发级别进行交互的好工具。
通过综合文档工作软件
TDD帮助创建工作软件。
客户合作谈判合同
（BDD）能够用通用语言描述规范并执行该程序非常棒。
响应遵循计划的变更
经过良好测试的代码库可以轻松更改。未经测试或经过严格测试的代码库是固定的。
也就是说，当时，项目中有值 正确的，我们更重视左边的项目。