前端自動化測試：TDD 和 BDD 哪個好？
TDD 原則
獨(dú)立測試
不同代碼的測試應(yīng)該相互獨(dú)立，一個類對應(yīng)一個測試類（對于 C 代碼或 C++ 全局函數(shù)，則一個文件對應(yīng)一個測試文件），一個函數(shù)對應(yīng)一個測試函數(shù)。
用例也應(yīng)各自獨(dú)立。每個用例不能使用其他用例的結(jié)果數(shù)據(jù)，結(jié)果也不能依賴于用例執(zhí)行順序。
一個角色：開發(fā)過程包含多種工作，如：編寫測試代碼、編寫產(chǎn)品代碼、代碼重構(gòu)等。做不同的工作時，應(yīng)專注于當(dāng)前的角色，不要過多考慮其他方面的細(xì)節(jié)。
測試列表
代碼的功能點(diǎn)可能很多，并且需求可能是陸續(xù)出現(xiàn)的，任何階段想添加功能時，應(yīng)把相關(guān)功能點(diǎn)加到測試列表中，然后才能繼續(xù)手頭工作，避免疏漏。
測試驅(qū)動
即利用測試來驅(qū)動開發(fā)，是TDD的核心。要實(shí)現(xiàn)某個功能，要編寫某個類或某個函數(shù)，應(yīng)首先編寫測試代碼，明確這個類、這個函數(shù)如何使用，如何測試，然后在對其進(jìn)行設(shè)計(jì)、編碼。
先寫斷言
編寫測試代碼時，應(yīng)該首先編寫判斷代碼功能的斷言語句，然后編寫必要的輔助語句。
可測試性
產(chǎn)品代碼設(shè)計(jì)、開發(fā)時應(yīng)盡可能提高可測試性。每個代碼單元的功能應(yīng)該比較單純，“各家自掃門前雪”，每個類、每個函數(shù)應(yīng)該只做它該做的事，不要弄成大雜燴。尤其是增加新功能時，不要為了圖一時之便，隨便在原有代碼中添加功能，對于 C++ 編程，應(yīng)多考慮使用子類、繼承、重載等OO方法。
及時重構(gòu)
對結(jié)構(gòu)不合理，重復(fù)等“味道”不好的代碼，在測試通過后，應(yīng)及時進(jìn)行重構(gòu)。
小步前進(jìn)
軟件開發(fā)是復(fù)雜性非常高的工作，小步前進(jìn)是降低復(fù)雜性的好辦法。
TDD 的優(yōu)點(diǎn)
保證代碼質(zhì)量，因?yàn)橄染帉憸y試，所以可能出現(xiàn)的問題都被提前發(fā)現(xiàn)了；
促進(jìn)開發(fā)人員思考，有利于程序的模塊設(shè)計(jì)；
測試覆蓋率高，因?yàn)楹缶帉懘a，因此測試用例基本都能照顧到；
TDD 的缺點(diǎn)
代碼量增多，大多數(shù)情況下測試代碼是功能代碼的兩倍甚至更多；
業(yè)務(wù)耦合度高，測試用例中使用了業(yè)務(wù)中一些模擬的數(shù)據(jù)，當(dāng)業(yè)務(wù)代碼變更的時候，要去重新組織測試用例；
關(guān)注點(diǎn)過于獨(dú)立，由于單元測試只關(guān)注這一個單元的健康狀況，無法保證多個單元組成的整體是否正常；
個人理解在前端應(yīng)用實(shí)際開發(fā)過程中 TDD 更適合開發(fā)純函數(shù)庫，比如 Lodash、Vue、React 等。
BDD
TDD 最大一個問題是在于開發(fā)人員最終做出來的東西和實(shí)際功能需求可能相偏離，為了解決這一問題有人發(fā)明了 BDD。BDD（Behavior-driven development）行為驅(qū)動開發(fā)，是測試驅(qū)動開發(fā)延伸出來的一種敏捷軟件開發(fā)技術(shù)。
BDD 解決的另外一個關(guān)鍵問題就是如何定義 TDD 或單元測試過程中的細(xì)節(jié)。一些不良的單元測試的一個常見問題是過于依賴被測試功能的實(shí)現(xiàn)邏輯。這通常意味著如果你要修改實(shí)現(xiàn)邏輯，即使輸入輸出沒有變，通常也需要去更新測試代碼。這就造成了一個問題，讓開發(fā)人員對測試代碼的維護(hù)感覺乏味和厭煩。
BDD 核心目的是為了解決 TDD 模式下開發(fā)和實(shí)際功能需求不一致而誕生，BDD 不需要再面向?qū)崿F(xiàn)細(xì)節(jié)設(shè)計(jì)測試，取而代之的是面向行為來測試。它是從產(chǎn)品角度出發(fā)，鼓勵開發(fā)人員和非開發(fā)人員（產(chǎn)品、QA、客戶等）之間的協(xié)作。由于 BDD 的核心是關(guān)注軟件的功能測試，所以 BDD 更多的是結(jié)合集成測試進(jìn)行，它是黑盒的。
BDD 的開發(fā)流程
1、開發(fā)人員和非開發(fā)人員一起討論確認(rèn)需求
2、以一種自動化的方式將需求建立起來，并確認(rèn)是否一致
3、最后，實(shí)現(xiàn)每個文檔示例描述的行為，并從自動化測試開始以指導(dǎo)代碼的開發(fā)
這樣做使得每一次的更改都較小并快速迭代，每次需要更多信息時都將其上移。每次自動化并實(shí)現(xiàn)一個新示例時，便為系統(tǒng)添加了一些有價值的內(nèi)容，并準(zhǔn)備響應(yīng)反饋。
理想中的 BDD 解決方案最流行的是 Cucumber。它的協(xié)作流程是這樣：
1、開發(fā)人員與產(chǎn)品、測試、客戶等人員溝通確認(rèn)需求
2、使用統(tǒng)一的 Gherkin 語法將功能需求轉(zhuǎn)換為需求文檔
用描述性自然語言定義的測試，客戶、測試人員和開發(fā)人員都能看得懂，能達(dá)成共識，這種語法叫做 Gherkin Syntax，小黃瓜語法。
以關(guān)鍵字 Scenario、Feature 等來描述場景
以關(guān)鍵字 Given、When、Then 來描述步驟
Feature: 添加任務(wù)Scenario: 在輸入框中輸入任務(wù)名敲回車確定，輸出到任務(wù)列表中Given "Hello World"When 在輸入框中敲回車Then 任務(wù)列表增加一個名稱為 "Hello World" 的任務(wù)Scenario: 在輸入框中輸入空內(nèi)容，不輸出到任務(wù)列表中Given ""When 在輸入框中敲回車Then 任務(wù)列表中不增加任何內(nèi)容
Cucumber 讀取使用 Gherkin 語法描述的純文本形式的可執(zhí)行規(guī)范，并驗(yàn)證該軟件是否滿足那些規(guī)范所說的內(nèi)容。規(guī)范包含多個示例或方案。
每個方案都是 Cucumber 要執(zhí)行的步驟的列表。Cucumber 驗(yàn)證軟件是否符合規(guī)范，并生成一個報(bào)告，指出每種情況的成功或失敗。
3、開發(fā)人員根據(jù) Gherkin 編寫測試用例
4、編寫代碼使測試通過
5、新增功能重復(fù)上述步驟
BDD 注重的是產(chǎn)品功能，可能無法保證很好的代碼質(zhì)量和測試覆蓋率，所以還有人提出一種方案就是 BDD + TDD。
BDD
– 需求分析
– 描述需求定義文檔
– 編寫集成測試用例
TDD
– 編寫單元測試用例
– 編寫代碼使單元測試通過
– 重構(gòu)優(yōu)化
編寫代碼使集成測試通過
增加功能重復(fù)上述步驟
個人理解也可以把 BDD 看作是在需求與 TDD 之間架起一座橋梁，它將需求進(jìn)一步場景化，更具體地描述系統(tǒng)應(yīng)該滿足哪些行為和場景，讓 TDD 的輸入更優(yōu)雅、更可靠。
還有一種更輕量的 BDD 方案就是以集成測試為主的開發(fā)方案。
需求分析
編寫集成測試用例
運(yùn)行測試
代碼實(shí)現(xiàn)使測試通過
重構(gòu)優(yōu)化
增加功能重復(fù)上述步驟
BDD 的優(yōu)點(diǎn)：
由于側(cè)重于需求功能的完整度，所以能給開發(fā)人員增加更多對程序的信心
由于僅關(guān)注功能，不關(guān)注實(shí)現(xiàn)細(xì)節(jié)，有利于測試代碼和實(shí)際代碼解耦
由于大多數(shù)為編寫集成測試，相比 TDD 有更好的開發(fā)效率
BDD 的缺點(diǎn)：
因?yàn)橐怨δ苄缘募蓽y試為主，因此不是那么關(guān)注每個函數(shù)功能，測試覆蓋率比較低
沒有 TDD 那么嚴(yán)格的保證代碼質(zhì)量
TDD vs BDD
個人推薦：
建議開發(fā)功能函數(shù)庫使用 TDD 方案
建議開發(fā)業(yè)務(wù)系統(tǒng)使用 BDD 方案
俗話說生活就像一場旅程，不必在乎目的地。雖然對生活來說這可能是正確的，但對開發(fā)應(yīng)用程序來說卻恰恰相反，你可以選擇單獨(dú)使用其中一種方法，也可以綜合使用這幾個方法以取得更好的效果。只要是編寫可節(jié)省時間的、有價值的測試就可以，如何編寫無關(guān)緊要。
前端自動化測試的權(quán)衡利弊
當(dāng)我們開始編寫自動化測試時，可能想要測試所有的東西。每個搬磚仔可能都體會過未經(jīng)測試的應(yīng)用程序帶來的痛苦，但在測試過程中，很快我又學(xué)到了另一課——測試會減緩開發(fā)速度。
在編寫測試時，請務(wù)必牢記編寫測試的目的。通常，測試的目的是為了節(jié)省時間。如果你正在進(jìn)行的項(xiàng)目是穩(wěn)定的并且會長期開發(fā)，那么測試是可以帶來收益的。
但是如果測試編寫與維護(hù)的時間長于它們可以節(jié)省的時間，那么你根本不應(yīng)該編寫測試。當(dāng)然，在編寫代碼之前你很難知道通過測試可以節(jié)省多少時間。但是，假設(shè)你正在一個短期項(xiàng)目中創(chuàng)建原型，或者是在一個創(chuàng)業(yè)公司迭代一個想法，那你可能不會從編寫測試中獲得收益。
凡事都有兩面性，軟件測試也不是銀彈，好處雖然明顯，卻并不是所有的項(xiàng)目都值得引入測試框架，畢竟維護(hù)測試用例也是需要成本的。對于一些需求頻繁變更、復(fù)用性較低的內(nèi)容，比如活動頁面，讓開發(fā)專門抽出人力來寫測試用例確實(shí)得不償失。
而適合引入測試場景大概有這么幾個：
需要長期維護(hù)的項(xiàng)目。它們需要測試來保障代碼可維護(hù)性、功能的穩(wěn)定性。
較為穩(wěn)定的項(xiàng)目、或項(xiàng)目中較為穩(wěn)定的部分。給它們寫測試用例，維護(hù)成本低。
被多次復(fù)用的部分，比如一些通用組件和庫函數(shù)。因?yàn)槎嗵帍?fù)用，更要保障質(zhì)量。
測試確實(shí)會帶給我們相當(dāng)多的好處，但不是立刻就能夠體會到。測試就像保險，如果身體健康順順利利，幾十年可能都用不上。測試也一樣，寫了可以買個放心，這就是對代碼的一種保障，有 bug 可以盡快測出來，沒 bug 最好，但不能說“寫那么多測試，結(jié)果測不出 bug，是浪費(fèi)時間”。
推薦閱讀：
前端工程化中的重要環(huán)節(jié)——自動化構(gòu)建
更新不易，點(diǎn)個“在看”和“贊”吧(●'?'●)！