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

[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 以概念來說,循環可以先簡化成下圖的方式:

ATDD循環

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

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

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

 

挑選一個 User Story

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

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

  1. User story 內容
  2. Priority
  3. 負責人
  4. 驗收測試案例

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

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

INVEST 指的是:

  1. I – Independent(獨立)
  2. N – Negotiable(可修改)
  3. V – Valuable (對使用者有價值)
  4. E – Estimable (可評估範圍)
  5. S – Small (夠小)
  6. 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 工具段落

 

自動化測試

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

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

 

撰寫實際功能內容

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

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

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

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

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

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

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

圖片來源:http://www.testingthefuture.net/2009/09/the-w-model/

 

User Story 與 ATDD

在 Scrum 的過程中,整個團隊在累積開發進度時,都是透過 user story 為單位來確認進度。把 ATDD 放在整個 Scrum 的 sprint 中,就如下圖所示:

圖片來源:http://www.methodsandtools.com/archive/archive.php?id=72p9

筆者一直在強調節奏,在 Scrum 的 sprint 中, user story 與 ATDD 的節奏就是:

  1. 挑一個 user story
  2. 撰寫 user story 的驗收測試案例
  3. 建立自動化測試程式
  4. 完成 user story
  5. 挑下一個 user story

 

ATDD 與 TDD 的關係

了解了 Scrum 的流程後,而 ATDD 與 TDD 的關係,用下面這張圖來表示,再清楚不過了:

圖片來源:http://www.methodsandtools.com/archive/archive.php?id=72p9

  1. 先撰寫 user story
  2. 為 user story 撰寫驗收測試案例
  3. 撰寫驗收測試程式
  4. 驗收測試結果失敗
  5. 撰寫整合測試案例
  6. 整合測試結果失敗
  7. 撰寫單元測試案例
  8. 單元測試結果失敗
  9. 撰寫實際程式
  10. 通過單元測試
  11. 重構單元測試涵蓋的範圍
  12. 重複 step7 ~ step11 ,直到整合測試通過
  13. 重複 step5 ~ step12 ,直到驗收測試通過
  14. 重複 step3 ~ step13,直到 user story 上的驗收測試案例全數通過
  15. User story 完成,挑下一個 user story

 

Scrum 流程的輔助

這樣可以在整個軟體開發的流程,讓整個團隊有著一定的節奏(這也是 Scrum 這個 framework 會定義一些固定的軟體開發流程的原因),這裡補上 Ruddy 老師 所畫的 Scrum 流程圖:

圖片來源(by Ruddy Lee):http://ruddyblog.wordpress.com/2011/04/03/scrum-%E8%AA%B2%E7%A8%8B%E5%9C%96%E7%A4%BA/


  1. 透過 Scrum 流程的輔助,來幫助每個角色在整個軟體開發流程中,各階段擁有一定的節奏。
  2. 透過 user story 與 ATDD的方式,讓開發人員與測試人員維持一定的節奏。
  3. 透過 ATDD 與 TDD 與重構,讓開發人員在撰寫實際的功能程式碼時,也可以維持一定的節奏與品質。

有了節奏,有了測試的保護,就可以快速小步前進,持續回饋,持續演進,而且能夠更客觀的預估團隊的產出進度,且可以凝聚團隊向心力,建立信任基礎,這就是整套 Scrum 預期達到的效果。

 

小結

就開發團隊來說,開發流程就如下圖所示,一環扣著一環:

ATDD TDD Refactoring

從 user story 開始,觸發 ATDD ,觸發 TDD ,觸發重構。

每一個環節,都是下一個環節的基礎。透過許多工具或開發方式,來降低每一個環節之間的轉換成本,讓每一個環節、每一個角色,最終目的都是產生一個最符合使用者需求的系統成品,這樣才是一個成功的軟體開發

 

ATDD 工具

這邊補充一下幾個常見的 ATDD 工具 (筆者比較喜歡表格式的呈現):

  1. Fit :官網
  2. FitNeese (像 wiki 的 Fit ) : 官網
  3. Selenium : 官網 ,也可以參考前面的修煉文: [30天快速上手TDD][Day 8]Integration Testing & Web UI Testing

這一系列會先以 Selenium 為主,當然還是可以輔以 Fit 或 FitNeese 來協助 user 或 PO 定義驗收測試案例。

如同前面系列文內容所示,透過 Selenium 可以幫助開發人員建立後續的自動化測試程式。

對敏捷開發有興趣的朋友,可以參考我的粉絲專頁:91敏捷開發之路

若需要聯絡我,可以透過粉絲專頁私訊或是側欄的關於我。