GDS Digital Service Manual 中文翻譯網站 (beta)
by HPX-GOV 英國政府數位服務研究小組 GDS Study Group

測試程式碼(Testing code)

如何確保你的程式碼運作一如預期的正確

GDS使用自動化測試:

  • 確保程式碼做好應做的工作
  • 確保程式碼具有防止惡意攻擊的保護
  • 保證程式可迭代出更好的設計,或新功能將不會產生錯誤

-在適當情況下,GDS也加入手工測試,作為一個額外的檢查。

自動化測試是我們對於品質 的整體思維的重要組成部分,但它只是其中的一部分。

方法

有各種各樣的方法來寫自動化測試。 特別來說,差異發生在人們對於測試的想定,也發生在他們的表達方式。

很多從業者堅持認為,自動化測試應該始終在尋求測試的程式碼編寫之前製作的(保證精心的設計和“足夠”的程式碼),而有些則是在程式碼完成後快樂的撰寫測試。那些在程式碼轉編寫之前製作的測試提供了一些優勢,這種做法值得鼓勵,但最重要的是整個團隊為了確保自動化測試而工作,這些測試被理解為產品的資產和他們幫助你確保你的程式碼質量。

常聽到有人談用行為驅動開發(BDD)作為一種替代測試驅動開發的方法。BDD是一種自動化測試方法論,側重於以“ 通用語言 “表達測試,以便於整個團隊在討論問題時分享。有各種方便的工具用來製作BDD測試,但它是一種可以用最傳統的工具來實現的方法。

測試類型

任何為你的服務編寫的程式碼都應有一套以兩個層級運作的測試:

驗收測試

這需要通過廣泛的、高等功能的端到端運行測試,確保該系統的子功能聚集在一起提供合適的服務。

在你的團隊的開發人員應該能夠以對產品經理 /服務經理有意義的方式,描述任何驗收測試的步驟,,去符合他們希望如何使用該服務(或者濫用!)

單元測試

這集中在程式碼的特定細節,確保每一個單獨的程式碼單元都能如預期般運行:

  • 允許開發人員驗證複雜的計算是否正確執行
  • 確保程式碼良好處理來自用戶的錯誤輸入
  • 確保程式碼的最佳化不會破壞它的行為

編寫測試時

當發現一個程式錯誤時,就寫一個測試。然後在程式錯誤被修復前,再寫一個測試以重現錯誤。這樣你就可以確認這個錯誤已經修復,並確保它是不會再發。

GDS設定在一個功能開始製作時,就開始製作第一組測試。描述程式碼的預期端到端的性能的驗收試驗可確保:

  • 人人參與去理解部分工作的目標
  • 進度可以透過過當前的用戶故事來展示

這些測試通常被描述為“快樂路徑”或“傷心路徑”:

  • 快樂路徑試驗確認在設計範圍內,該系統可以使用
  • 傷心路徑試驗確認,系統能順暢的處理錯誤(不管是使用者的錯誤輸入、一個關鍵的 API失效,或者一些其他的問題)

GDS由快樂路徑測試和一些簡單的悲傷路徑測試開始,然後作為程式碼的理解和它的相依發展增添更多悲傷路徑測試。

及早並經常測試

開發者期待定期測試,尤其在分享新的程式碼之前。作為審查過程的一部分,在測試中檢查的程式碼,並在一個共享的持續整合系統定期進行測試。這給整個團隊一個機會,看看他們是如何執行。

譯者:陳群岳
校稿者:
原始出處:https://www.gov.uk/service-manual/making-software/code-testing.html

請留言

你的email信箱不會被發布出來. Required fields are marked *

*