2022-05-16|閱讀時間 ‧ 約 3 分鐘

LeSS in Action - 驗收測試驅動開發

完成對功能的了解之後，我們就要開始進入實現功能的開發階段。跟以往的開發流程不同的是，我們在敏捷開發中注重的是製作有價值的東西。也就是在計畫中，我們獲取的資訊都是對使用者有用、可以被看見以及操作和跨團隊協作的性質。

Acceptance Test Driven Development

驗收測試驅動開發（A-TDD）很容易跟 TDD（Test Driven Development，測試驅動開發）搞混，兩者是不一樣的概念。前者是關注的是溝通以及「用測試驗收更可靠」的概念，而後者則是一種開發上的技巧。

基於驗收測試開發的實踐，我們根據 PBI（Product Backlog Item）中細化（Detailing）後的關鍵案例（Key Examples）來撰寫驗收測試，這個資訊大多會包含：

我們關注的是每一個功能（Feature）以及對應的情境（Scenario）發生的事情，這也是為什麼我們要進行衝刺計畫（Sprint Planning）來細化產品需求，將它轉換為實際的功能資訊。

因為使用「測試」我們很容易誤會要進行所有的檢查，然而 A-TDD 更加接近於「確認」這件事情上，因此我們每一個測試案例都是以「確認功能正常」為前提所撰寫。

因為我們基於 A-TDD 所撰寫了端對端（End to End）的測試案例，這也表示我們能夠用 TDD 的方式進行開發，採取「小步前進」的方式進行。

從使用者的角度來看，我們在初始的階段中只需要讓「文章列表找不到特定文章」的事情發生即可，因此我們很可能會直接在畫面中隱藏這篇文章，等待通過測試後，再繼續增加更細節的實作，直到我們完整的實現符合專案需求的功能。

透過這樣小步前進的方式，我們可以維持測試經常性的保持綠燈，也更容易在發生錯誤時倒退（Revert）回到上一個正常的階段繼續進行工作。

封面圖片使用 Unsplash 上 John Schnobrich 的作品，這系列的文章只是課程的一小部分，因此並無法完整涵蓋所有概念以及精神，看關於技術的主題可以到弦而時習之找找靈感。

分享至

成為作者繼續創作的動力吧！