測試驅動指引概念測試驅動開發（Test-DrivenDevelopment，TDD），用一句話講，就是“寫代碼只為修復失敗了的測試”。我們先寫一個測試，然后再寫代碼讓測試通過。當我們在當前結構中找出最佳設計時，由于有足夠的測試做保障，我們可以放心地改動現有設計而不必擔心破壞已完成的功能。使用這種開發方法，我們可以讓設計更加優良，能編寫出可測試的代碼，同時還能避免在不切實際的假設基礎上過度地設計系統。要得到這些好處，只需不斷添加可執行測試，一步步地驅動設計，從而最終實現整個系統。這種短開發周期的開發方式與舊方式有很大不同。我們習慣于先設計，然后編碼實現，最后做一些并不完備的測試。（我們都是優秀的程序員，很少犯錯，所以稍加測試即可，不是嗎？）TDD完全顛倒了整個過程。我們會先寫測試描述出目標，然后寫代碼達到這個清晰的目標，最后再設計——在已有代碼的基礎上找出最簡單的設計。隨著TDD不斷深入到開發領域，這種測試先行的思想也不斷向上深入到需求階段，衍生出來ATDD、BDD等相關方法。目標通過TDD提高應用程序內部質量，通過ATDD/BDD確保交付客戶的軟件符合用戶需求。即在編碼層面，我們用TDD方法以測試驅動的方式編寫代碼。在需求層面，我們使用類似的BDD方法以測試驅動的方式構建系統。原則先寫測試代碼，然后編寫符合測試的代碼。至少做到完成部分代碼后，完成對應的測試代碼。測試代碼不需要覆蓋所有的細節，但應該對所有主要的功能和可能出錯的地方有相應的測試用例。發現bug，首先編寫對應的測試用例，然后進行調試。不斷總結出現bug的原因，對其他代碼編寫相應測試用例。不斷維護測試代碼，保證代碼變動后通過所有測試。不斷維護測試代碼，提高測試代碼的可讀性與可維護性。遵從測試金字塔，數量上來說UT>BDD>手工測試。規范綜合必須：測試代碼也是代碼，需要源代碼管理。必須：測試代碼不需要再寫測試代碼，但需要代碼評審。必須：單元測試、BDD測試的代碼和項目代碼放在同一個代碼工程里，用不同目錄區分。必須：用于回歸的E2E測試代碼可以放到與項目代碼不同的工程中。必須：單元測試、驗收測試以及BDD可以自動化執行。必須：不同技術?？梢圆捎貌煌淖詣踊瘻y試框架，但是都需要能夠接入DevOps平臺。即可以由平臺觸發測試，并反饋測試狀態和結果。必須：每次push都會觸發單元測試，并反饋測試結果。建議：每次push都會觸發BDD測試，并反饋測試結果。建議：每日運行一次全量回歸的E2E測試，并反饋結果。單元測試建議：工程名：[ProjectName].Unit.Tests。如：項目工程為abc.service，那么單元測試工程為abc.service.unit.tests。建議：文件名：[ClassName]Tests。如：bookService.java,測試類為bookServiceTests.java。建議：方法名：由三部分構成，[name_of_method]_[scenario]_[expected_behavior]，如：Add_SingleNumber_ReturnsSameNumber。必須：方法結構：遵從Act-Arrange-Assert結構。如unittestmethodstructure展開源碼BDD必須：不要嘗試用BDD取代單元測試！開發人員應該先干好自己的單元測試。建議：當項目中的BDD完整執行需要超過15分鐘，改進測試代碼。必須：BDD測試使用Gherkin風格的描述語言，即Given-With-Then。建議：feature都放置在項目的src/tests/features/文件夾，可以按照不同功能集合，建立不同子目錄。建議：step定義放置在項目的src/tests/features/steps/中，子目錄結構與保持與features/子目錄一致。建議：每一組近似功能的測試，放到同一個.feature文件中。如：src/tests/features/useraccount/signup.feature，放入注冊相關的測試。建議：每一個feature包含的特性集，必須能夠獨立運行。不同的feature測試之間不互相影響。建議：不要嘗試通過文件名建立feature和用戶故事的關聯關系。如：features/sotry_38971_log_in.feature。推薦實踐開發階段QA為用戶故事編寫BDD用例，完成后須于SDE/TPM確認。SDE編寫單元測試與業務代碼，并且協助QA編寫BDD代碼。測試!每一次codecommit，DevOps產出2個結果：1-本次提交的UT結果；2-本次提交對測試覆蓋率的影響。mergerequest產生后，每一次commit，還會多1個結果：BDD測試結果。建議每日夜間進行回歸測試，并將測試報告推送給全體團隊成員。QA協助TPM為下一沖刺的故事編寫驗收條件，只有驗收條件通過BDD編寫