重寫的專案我會要求用 BDD 來開發，原因無它：因為寫好的文件就可以拿來驗證程式碼。如果你覺得寫文件很浪費時間，不如寫程式一次搞定，那麼 BDD 絕對會是你應該試試的開發模式。因為常見的 BDD 框架通常是採用 Gherkin 語法來描寫功能 (feature) ，這使得文件本身很好讀，又容易轉換成驗證用的 context 程式，所以也很適合用在 PM 與開發者合作；也就是 PM 寫 feature ，讓開發者用 feature 來驗證自己寫的程式碼。
BDD 通常是以情境來當驗證案例，所以前面收集到的規格和情境很適合用在這裡，也因此 BDD 通常會結合 e2e 測試來進行。這麼一來文件的更新，也會影響到測試是否能夠通過，就不會再發生文件和程式碼不一致的情況了。