測試程式碼（Testing code）

GDS使用自動化測試：

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

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

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

方法

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

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

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

• Dan North “BDD 簡介”
• 維基百科上的BDD

測試類型

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

• 驗收測試
• 單元測試

驗收測試

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

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

單元測試

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

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

編寫測試時

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

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

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

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

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

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

及早並經常測試

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

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