从敏捷宣言，敏捷值：测试驱动开发敏捷？
个体和交互胜过流程和工具，
工作的软件胜过面面俱到的文档，在合同谈判
客户合作，
回应按照计划更改
然而，TDD并没有制定计划，几乎可以构建合同谈判？
“你想要什么功能？” “1,2,3” 开发为1,2,3编写测试 - >团队提供代码 “这里的1,2,3赋予我们的钱”
这也是全面的文档，并一户一表处理。一旦测试被写入个人和交互不再重要，因为“代码的真相”不再与人们在一起，而是在代码中被剔除。
只是想知道他们如何配合在一起，如果他们反对或他们一起工作？
TDD更像是个人贡献者的实践，而不是一个过程。这里的测试通常是指单元测试，这是开发工作的一部分，而不是全面的测试套件，如性能，功能和集成测试。
TDD在某些情况下应该有助于个人贡献者真正考虑需求和实现（响应变化并提供工作软件）。我个人不会采用这种做法，但这是一种敏捷的做法，可以由单一贡献者采用。不要将它与更高级别的测试和相关文档混淆。
好的，这很有帮助，它更像是开发人员之间的合同，任何关于为什么有些人似乎为这个问题而生气的见解？ – user2483724
TDD是一种高度依赖个性的做法，有些人喜欢在购物前将每件商品都写在列表中，并在流程中逐一排列出来，而其他人只是试图记住事物并在现场抓取。来证明这种交易的合理性，而且这很大程度上取决于任务的范围（通常也是灵活的），这与结对编程有点类似，但有些人觉得很高兴有陪伴， nd其他人感觉更好，以保持一些私人思维空间。 – miushock
但不TDD创建一个计划
都能跟得上。 TDD并不意味着“先写测试”，这意味着“在编写代码之前编写测试”。整个“尽你所能，不再需要”发挥作用。在编写任何代码之前，您不需要编写所有功能的测试，只需要您现在使用的功能即可。然后（取决于测试级别）功能的一小部分将需要测试现在。
这也是全面的文档的一种形式，还需要一个过程
它还可以工作的软件帮助。
工作的软件超过全面的文档，
过，而不是替代。如果你能得到这两个，很好。
测试是书面的个人和交互不再重要，因为“真相的来源”不再与人，但在代码中被淘汰。
oracle为它做什么始终是代码。 oracle为它应该做什么永远是人。 TDD做得很好也有助于沟通。
任何有关为什么有些人似乎在这个问题上生气的见解？
问题来源于非常巨大的问题。你正在扭曲宣言，使其听起来像任何援助后者是“坏”的东西，而你正在扭曲TDD的定义，使其成为一个包罗万象的完全预先过程。这两者都不是真的。
个体和交互胜过流程和工具，
BDD是在开发/ BA /火刑架的水平辅助作用的好工具。 TDD（xUnit和alikes）是帮助开发人员交互的强大工具。
了全面的文档
TDD工作的软件可以帮助创建工作的软件。
在合同谈判
（BDD）能够在一个共同的语言来描述规范和有执行客户的协作是真棒。
响应遵循计划
良好测试的代码基底可以易于改变来改变过。未经测试或严重测试的代码库已修复。
也就是说，虽然上有 权中的项目价值，我们更看重左边多个项目。
感谢您的分解！自从我问这个问题已经有一段时间了，但我从那时起就已经知道“测试”实际上是一个广泛的概念，而且人们经常会对“正确的方式”进行半宗教的争论。国际海事组织现在，测试和敏捷实际上是分开的想法，几乎在同一时间产生，但是相互联系。敏捷需要快速部署和发布反馈和测试，从而使这些发布不会发生呃逆。测试在敏捷之前就已存在，但之前未用于此类快速部署。 – user2483724
请记住，（大A）敏捷只是一堆人们已经写下来的东西。然后由一些成为一个宗教。 –
我同意汤姆的回答，“如果可以做得很好，那么我相信这总是一件好事。如果不可能做得好，那么我认为它可能是有害的。“敏捷根本不是每个公司的正确答案。在一家大公司做得不好，而且对软件架构的关注不足，会影响最终技术的实用性。 Digital Animal撰写了一篇关于敏捷的有趣文章，以及为什么它不适合他们。 http://digitalanimal.com/blog/slaying-the-agile-dragon-the-game-of-thrones-methodology/?AT=D8c953
这似乎只是玩字。 –
没有办法解决或证明这一点。它可能不适合[SO]（http://stackoverflow.com/help/on-topic），IMO。 –
好吧，答案是这样的：“尽管敏捷宣言似乎违背了TDD，但这只是一个浅薄的解释。实际上，它们一起工作是因为......”或“它们完全不相关”或“它们不应该一起使用“ – user2483724