從敏捷宣言，敏捷值：測試驅動開發敏捷？
個體和交互勝過流程和工具，
工作的軟件勝過面面俱到的文檔，在合同談判
客戶合作，
迴應按照計劃更改
然而，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