TDD之團隊進行單元測試的規範

近期，給項目化開發人員做技能培訓時，整理了一下團隊在DOD中對於單元測試最佳實踐和要求，作為單元測試規範，如下：

【原則】開發人員在編寫代碼過程中需要恪守的基本準則，在日常工作中需要在基本原則的指導下完成代碼開發任務。

【規則】開發人員在日常開發過程中必須嚴格遵守的規則，這是系統代碼得以正常穩定運行的基礎，是以團隊合作方式進行軟體開發的基本保證。

【建議】建議部分提出的內容，希望員工能夠盡量遵守，這些內容是經驗豐富的開發人員在長期開發中積累的寶貴經驗教訓，有助於編寫出高質量的代碼。

【原則1】遵循TDD三原則（定律）

• 沒有用例失敗時，不要寫產品代碼
• 當有用例失敗時，不要寫更多的用例
• 僅寫讓用例通過的代碼

【原則2】TDD遵循測試的FIRST原則

• F(Fast)：測試要能快速運行
• I(Isolate)：測試用例要獨立，不能相互依賴
• R(Repeatable)：測試要可以重複運行
• S(Self-verifying)：測試會自己檢查產出
• T(Timely)：測試要及時做，與寫代碼緊密相連

【原則3】TDD是開發行為，是DOD

• TDD是開發必須的基本技能
• 交流的基本語言
• DoD-開發完成的定義，團隊成員認可，不斷擴充

【原則4】代碼是債務，單元測試用例也是，優先修復並且不斷重構

【規則1】每一個用例測試一個概念/功能

測試用例遵循SRP。當測試失敗時，很容易知道用例失敗的原因。

【規則2】測試名稱遵循BDD（Gievn-When-Then）書寫模型：Given/When/Then

假如[當測試開始時，系統所處狀態的一些重要特徵]，當[用戶執行某些動作後]，那麼[系統新的狀態的一些特徵]

TEST(RecurrNonProrateStateChangeReactiveTest, GivenFeeIs100$PerMonthAndBenefit100SMS_WhenReactiveAt20thJanuary_ThenDeduct100$AndBenefit100SMS)

【規則3】測試用例按照構造數據/執行功能/檢測結果進行代碼分塊

用例編寫也遵循BDD（Gievn-When-Then）書寫模型。並按照構造數據/執行功能/檢測結果分塊。

【規則4】將具有相同測試環境的用例放在同一個測試套件中

將構造測試環境及清理測試環境的代碼分別放在 Setup及 Teardown 中，可以消除重複的代碼，實現代碼的最大可復用性。

【建議1】用例業務場景複雜時，可以通過注釋提高可讀性

除了用例名稱，可以通過注釋可以詳細描述用例的測試場景。

【建議2】通過用例套件來測試跨進程間的協議正確性

例子：SY測試時，OCPro生成內部消息，轉發給你進程sydealsnr來處理。可以在一個套件來測試這兩個用例，並嚴重介面。

TEST_F(TTest_OcproSendSNRMsg, GivenTriggerPCRF_WhenOcproUSURating_ThenOcproSendSnrMsgSucessful)

TEST_F(TTest_OcproSendSNRMsg, GivenSySpInfo_WhenSyDealSnrReceiveMsgFromOcpro_ThenReturnSnrAVPSucessful)

　【建議3】用例代碼和業務代碼獨立，並且建立對應目錄，在內部可以按照業務分層建立目錄。

　【建議4】每個用例套件一個獨立的CPP文件。用例公用代碼文件以gtest_來區分業務代碼。

【建議5】用例數據保持無關，保證可以並行執行，提高運行速度

因為歷史原因或者特殊原因，無法做到數據獨立，用例非utest_開頭，優先串列執行；文件名以utest_前綴的用常式序並行執行。

【建議6】為了方便驗證功能，某些特殊場景也可以直接測試private和protected函數

在對應頭文件包含前加上轉移說明

#include "gtest/gtest.h"

#define private public

#define protected public

#include "DAOInterface.h"

因為每個未證明正確的代碼都是有嫌疑的，因此新增單元測試用例的最佳時機就是新增功能和修復功能之前。

來源： 51Testing軟體測試網

https://mp.weixin.qq.com/s/JAZwVFTeKwvQnadUcbUyhg