TDD：單元測試重點

Question

TDD能否面向與單元測試不同的另一種測試？

Answer 1

雖然在TDD的一些解釋下可能有可能，但我認為TDD的要點是在任何生產代碼之前編寫測試。 鑒於這種情況，你會不會有一個大的系統集成寫或功能測試，所以測試必然將是在單位層面。

Answer 2

行為驅動開發 （BDD）在集成測試和功能測試級別應用TDD的思想。

Answer 3

TDD的紅綠重構循環應該很快，非常快。 快速反饋讓您陷入困境。 我已經看到了TDD的方法，它講述了一個完整的故事，將其表達為測試，然后推動開發以通過該（大型）測試。 它名義上是TDD（或者可能是BDD），但對我來說感覺不對。 微小的步驟，單元測試，是我學習TDD的方式，我如何看待它，以及它如何最適合我。

Answer 4

從技術上講，TDD是一種做事方式，而不僅僅是單元測試，理論上它應該驅動所有的開發過程。

從理論上講，理念是測試驅動開發，對於更復雜的場景，比如系統之間的集成，你應該定義集成測試，然后代碼通過那些集成測試（即使測試不是自動化的）......

Answer 5

當然是的。 TDD依賴於自動化測試，這是對“類型”測試的正交考慮。

Answer 6

如果你專注於想法，而不是技術實現，而不是。 我所說的是，只是片刻，你忘記了單元測試，並且在編寫實現之前首先關注編寫測試的想法，以便實現更清晰的設計，甚至可以在系統級別上完成。

想象一下，你有一些要求。 基於此，您編寫用戶驗收測試測試 - 在高級別上捕獲功能的測試。 接下來，您將開始開發 - 您已經擁有UAT測試形式的用例。 您確切知道預期的內容，因此更容易實現所需的功能。

其他例子是基於scrum的項目。 在計划會議中，您將討論/創建/擁有稍后在sprint期間開發的用戶故事。 那些用戶故事實際上可以是UAT測試。

無論如何，我認為TDD是預先指定設計的方式，而不是應用程序測試周期/階段/方法。 TDD被視為單元測試的同義詞的原因是單元測試盡可能接近開發人員。 它們似乎是開發人員表達類/方法的功能設計的自然方式。

Answer 7

當然！ TDD不需要單元測試，根本不需要。 不幸的是，這似乎是一種常見的誤解。

舉一個具體的例子，我完全用集成測試來驅動我的開源模擬庫（用於Java）的開發。 我不為內部類編寫單獨的單元測試。 相反，對於每個新功能或增強功能，我首先添加一個失敗的接受（集成）測試，然后更改或添加到現有的生產代碼，直到測試通過。 通過最終的重構步驟，即使沒有編寫單元測試，這也是純TDD。