經歷了好幾天的解說，終於把 TDD 的測試說完了，我們介紹了好幾個套件：RSpec, Capybara, Factory_bot，因為有太多東西可以說了，礙於時間，沒辦法講得太深入。

結束了 TDD 的介紹，當然就是要進入另一個測試模式: BDD 囉！

不過在介紹 BDD 之前

我們要來談談 TDD 的缺點：

排擠非工程師背景的人員

在 TDD 的測試模式下，看似完善且理想的一套流程，但因為 TDD 本身還是著重在工程師本身的語言上，使得除了 RD 以外的人，都無法完全理解測試案例。

舉個簡單的例子，如上圖，非程式背景的人，可能就無法理解：「 wallet = MobileWallet.new(50) 」在幹嘛？那是什麼意思？

所以在測試時，只有工程師本身知道測試案例內的條件與情境，這樣的風險就是，可能會導致需求與程式不一致。

為什麼會需求與程式不一致？

因為專案的需求只有 PM 最知道，PM 必須將需求完全敘述給工程師，讓工程師寫程式，所以 PM 跟工程師之間的溝通就變得很重要。

如果今天工程師對 PM 的敘述理解 8 成，這 8 成呈現在規格上時，PM 無法完全理解規格上的程式碼時，就可能會導致不一致，因為 PM 可能會漏掉工程師未理解的那 2 成。

小結

那要如何解決這個問題，就是新的測試模式誕生的原因。下一篇會來介紹這個新的模式 BDD，敬請期待。