測(cè)試驅(qū)動(dòng)指引

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