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