[30天快速上手TDD][Day 22]ATDD - ATDD的循環 | In 91 - 點部落

2013-01-08

[30天快速上手TDD][Day 22]ATDD - ATDD的循環

前言

上篇文章簡單扼要的說明了，如何透過驗收測試案例，來輔助驗證 user story 是否已經完成。

也強調了驗收測試案例的基本 feature ，該由哪些共同協同合作撰寫，以及這麼做的目的和好處。

接著這篇文章，則是要說明一下在軟體開發流程中，使用 ATDD 來進行的循環與過程。

介紹

TDD 可以讓開發人員用小步伐的節奏慢慢累積可正常運作、且符合開發人員預期的程式碼。但 ATDD 關注的不一定是技術層面的事，而是在功能層面上確保「這個 working software 是否真的符合了使用者的需求」。

一開始透過 user story 抽象地定義使用者的需求，再依據如何定義 user story 已經完成，接著將其 break down 為驗收測試案例。

有了驗受測試案例之後，我們才會開始著手建立一個可行走的骨架（Walking Skeleton），也就是先定義好使用者要什麼，才會明白系統或功能要怎麼撰寫。

定義好最後要怎麼通過驗收測試，才代表撰寫完成的系統或功能符合最終的需求。

ATDD的循環

先前有稍微提到 TDD 的循環，如下圖所示：

圖片來源：http://reddevnews.com/articles/2007/11/01/testdriven-development-tdd.aspx

ATDD 以概念來說，循環可以先簡化成下圖的方式：

前提當然是 user , PO 與測試人員先擬定好了 user story（若在 Scrum 中，可能是 PO 依照 sprint backlog 來定義對應的 user story ），接著按照四個步驟的循環來進行：

挑選一個 user story
撰寫驗收測試案例
自動化測試
撰寫實際功能內容

跟 TDD 很像，不是嗎？接下來我們針對這四個步驟來進行說明。

挑選一個 User Story

怎麼挑選一個合適的 user story ，這在實務上的眉角也很多，有興趣想深入了解的讀者，一樣請去讀 Mike Cohn 的 User Stories Applied ，筆者這邊只列出最簡單的原則：根據 priority 來選擇。

前面兩篇文章有提到， user story 通常上面要記錄幾個東西：

User story 內容
Priority
負責人
驗收測試案例

User story 通常由 sprint backlog 而來， sprint backlog 由 product backlog 而來。

User story 在設計時，通常也有許多原則要遵循，例如： INVEST model 。

INVEST 指的是：

I – Independent（獨立）
N – Negotiable（可修改）
V – Valuable （對使用者有價值）
E – Estimable （可評估範圍）
S – Small （夠小）
T – Testable （可測試）

而滿足了這些原則，就會減少一些實務上挑選 user story 綁手綁腳的問題發生。（例如 user story 的相依性，影響到挑選的順序）

撰寫驗收測試案例

如同上一篇文章： [30天快速上手TDD][Day 21]ATDD - Acceptance Testing 所提到的，用 user story card 記錄 user story ，可以在其背面記錄驗收測試案例，由 PO ( user ), 測試人員與開發人員一同撰寫。

只專注在要測試的幾件事，也就是完成 user story 需要達成的幾件事。注重 What ，不注重 How 。建議可以透過一些工具輔助，以降低使用者或 PO 抗拒，並減少未來轉換成測試程式的成本，如文末補充的 ATDD 工具段落。

自動化測試

我們定義好需求之後，就是定義怎麼樣叫做完成需求。所以撰寫測試來驗證，功能是否符合預期。測試寫好之後，才來填肉，目標就是讓系統的程式碼通過測試。

簡單的說，除非測試案例寫錯，否則程式碼只要通過測試，就代表它是對的、是符合最終使用者的需求。這也是為什麼驗收測試案例需要各個角色的參與。

撰寫實際功能內容

為了要先滿足驗收測試案例，通常系統面的工作會先浮現出來，例如：

prototype :
我們需要一個 prototype ，而且這個 prototype 可以讓使用者認同與驗收。它是一個 working software ，即使不完全，也可以表達出 user story 所需要的功能。
環境：
可能需要有測試機、測試 DB 、測試資料、測試 file server 、模擬的外部服務、介接的系統介面、使用的協定與資料格式。

這一些東西會被強迫在系統剛開始建置時，程式碼撰寫之前，一一浮上檯面。

這些東西在許多瀑布式或是一般專案中，可能都會等到程式碼開發完成才開始進行，但那時倘若出現一些差錯，都可能導致整個程式碼需要重新翻修。

透過 ATDD ，第一步就是先建立可行走的骨架（Walking Skeleton），在撰寫任何程式碼之前，先確定環境建置，該透過模擬的元件或服務，系統的邊界，都會先被確定下來，以避免未來異動風險過高，或是不符合使用者需求的情況發生。

接著由 user story 整理出驗收測試案例，透過驗收測試案例產生整合測試案例，透過整合測試案例產生單元測試案例，一環扣著一環， top-down 的往下設計下去，目標都是符合最終使用者的需求。填肉的過程則是有點 bottom-up ，但那無所謂，因為填肉的過程目標明確，每一塊肉，就是為了滿足某個測試案例而存在。

最終，原本的 V-Model就會演化成 W-Model ，如下圖所示：