TDD、ATDD、BDD&RBE分別是什么

這篇文章主要講解了“TDD、ATDD、BDD&RBE分別是什么”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“TDD、ATDD、BDD&RBE分別是什么”吧！

在目前比較流行的敏捷開發(fā)模式（如極限編程、Scrum方法等）中，推崇“測(cè)試驅(qū)動(dòng)開發(fā)（Test Driven Development，TDD）”——測(cè)試在先、編碼在后的開發(fā)實(shí)踐。TDD有別于以往的“先編碼、后測(cè)試”的開發(fā)過程，而是在編程之前，先寫測(cè)試腳本或設(shè)計(jì)測(cè)試用例。TDD在敏捷開發(fā)模式中被稱之為“測(cè)試優(yōu)先的編程（test-first programming）”，而在IBM Rational統(tǒng)一過程（Rational Unified Process，RUP）中被稱為“測(cè)試優(yōu)先的設(shè)計(jì)（test-first design）”。所有這些，都在強(qiáng)調(diào)“測(cè)試先行”，使得開發(fā)人員對(duì)所做的設(shè)計(jì)或所寫的代碼有足夠的信心，同時(shí)也有勇氣進(jìn)行設(shè)計(jì)或代碼的快速重構(gòu)，有利于快速迭代、持續(xù)交付。重構(gòu)的前提就是測(cè)試就緒（testing is ready），在這樣的前提下，重構(gòu)的風(fēng)險(xiǎn)就很低，否則就有比較高的風(fēng)險(xiǎn)。

TDD具體實(shí)施過程，可以看作兩個(gè)層次，如圖1所示：

1. 在代碼層次，在編碼之前寫測(cè)試腳本，可以稱為單元測(cè)試驅(qū)動(dòng)開發(fā)（Unit Test Driven Development，UTDD）

2. 在業(yè)務(wù)層次，在需求分析時(shí)就確定需求（如用戶故事）的驗(yàn)收標(biāo)準(zhǔn)，即驗(yàn)收測(cè)試驅(qū)動(dòng)開發(fā)（Acceptance Test Driven Development，ATDD）。

圖1  TDD的兩個(gè)不同層次

先來討論UTDD，如圖2 所示。在打算添加某項(xiàng)新功能時(shí)，先不要急著寫程序代碼，而是將程序可能會(huì)碰到的特定條件、邊界值、上下文等想清楚，為待編寫（類或方法）的代碼先寫好測(cè)試腳本。然后，利用集成開發(fā)環(huán)境或相應(yīng)的測(cè)試工具來執(zhí)行這段測(cè)試用例，結(jié)果自然是通過不了（失?。＠脹]有通過測(cè)試的錯(cuò)誤信息反饋，了解到代碼沒有通過測(cè)試用例的原因，有針對(duì)性的逐步地添加代碼。為了要使該測(cè)試用例通過，就要補(bǔ)充、修改代碼，直到代碼符合測(cè)試用例的要求，獲得通過。測(cè)試用例全部執(zhí)行成功，說明新添加的功能通過了單元測(cè)試，可以進(jìn)入下一個(gè)環(huán)節(jié)。這樣的流程也適合代碼修改或重構(gòu)，真正執(zhí)行時(shí)，也不會(huì)嚴(yán)格按照這樣的流程去做，但最基本要求是：先寫好測(cè)試腳本（代碼），再寫產(chǎn)品代碼并通過測(cè)試。按照UTDD做法，不是先寫產(chǎn)品代碼的類，再寫測(cè)試類，而是先寫測(cè)試類，再寫產(chǎn)品的類。

圖2   UTDD執(zhí)行的過程

UTDD從根本上改變了開發(fā)人員的編程態(tài)度，開發(fā)人員不能在像過去那樣隨意寫代碼，要求寫的每行代碼都是有效的代碼，寫完所有的代碼就意味著真正完成了編碼任務(wù)。而在此之前，代碼寫完了，實(shí)際上只完成了一半工作，遠(yuǎn)沒有結(jié)束，因?yàn)閱卧獪y(cè)試還沒執(zhí)行，可能會(huì)發(fā)現(xiàn)許多錯(cuò)誤，一旦缺陷比較多，缺陷就比較難以定位與修正。UTDD在于促進(jìn)開發(fā)人員思考功能特性的應(yīng)用場(chǎng)景、異常情況或邊界條件，寫出更完善的代碼，避免犯較多的錯(cuò)誤。其次，也確保測(cè)試具有獨(dú)立性，不受實(shí)現(xiàn)思維的影響，確保測(cè)試的客觀、全面。這一點(diǎn)，對(duì)開發(fā)人員測(cè)試自己的代碼是必要的。如果是倒過來，先寫產(chǎn)品代碼（即功能實(shí)現(xiàn)在前）再進(jìn)行測(cè)試，那么測(cè)試會(huì)受實(shí)現(xiàn)思維影響。例如，我們自己寫的文章自己檢查，有時(shí)很明顯的問題都發(fā)現(xiàn)不了，就是受實(shí)現(xiàn)思維的影響。一般來說（多數(shù)情況下），開發(fā)人員測(cè)試自己的代碼有兩個(gè)障礙：思維障礙和心理障礙。心理障礙是指開發(fā)人員對(duì)自己的代碼不會(huì)窮追猛打，發(fā)現(xiàn)了一些缺陷，很可能會(huì)適可而止。我們知道，實(shí)際上缺陷越多的地方越有風(fēng)險(xiǎn)，越要進(jìn)行足夠的測(cè)試。最后，UTDD也確保所有代碼的可測(cè)試性，每一行代碼得到了測(cè)試，比較徹底地確保代碼的（微觀）質(zhì)量。

許多研發(fā)人員不習(xí)慣UTDD這種模式，推行UTDD會(huì)遇到比較大的困難，那TDD的實(shí)施可以移到業(yè)務(wù)層，推行ATDD，即在設(shè)計(jì)、寫代碼之前，明確系統(tǒng)功能特性的驗(yàn)收標(biāo)準(zhǔn)，這比較容易推廣實(shí)施。例如，在敏捷開發(fā)模式中，每個(gè)用戶故事的描述過于簡(jiǎn)單，是不具有可測(cè)試性的。例如，開發(fā)一個(gè)在線旅游網(wǎng)，可以提供交通、酒店、門票等預(yù)定服務(wù)，有一個(gè)最基本的用戶故事：

像這樣的用戶故事，如果不加驗(yàn)收標(biāo)準(zhǔn)，開發(fā)實(shí)現(xiàn)起來很容易，在數(shù)據(jù)庫某個(gè)表中刪除一條記錄，在其它關(guān)聯(lián)表上修改相應(yīng)的標(biāo)志位即可。但實(shí)際的業(yè)務(wù)不會(huì)那么簡(jiǎn)單，說取消就取消？不需要有一個(gè)時(shí)間提前量？取消一定成功嗎？收不收相關(guān)的費(fèi)用？是否需要線下處理的時(shí)間？是否需要通知用戶？通過什么方式通知取消成功或失敗？要回答這些問題，就是要給這個(gè)用戶故事增加“驗(yàn)收標(biāo)準(zhǔn)”，如：

• 取消前，需要提醒用戶再次確認(rèn)

• 需提前24個(gè)小時(shí)取消

• 需要4個(gè)小時(shí)處理時(shí)間，才能知道取消成功與否

• 這類取消需要收取總金額10%的費(fèi)用

• 不管取消成功與否，采用郵件和短信雙重通知

• 用戶事后可以查詢?nèi)∠南嚓P(guān)記錄

• 需要保留客戶和旅行網(wǎng)雙向操作記錄日志

這樣，這個(gè)用戶故事才具有可測(cè)試性，開發(fā)人員也會(huì)清楚如何實(shí)現(xiàn)這個(gè)用戶故事，實(shí)現(xiàn)的結(jié)果和產(chǎn)品經(jīng)理所期望的結(jié)果就不會(huì)有太大差異。

從ATDD演化出來一種具體落地的開發(fā)模式就是BDD（Behavior Driven Development，行為驅(qū)動(dòng)開發(fā)）。BDD只是將驗(yàn)收標(biāo)準(zhǔn)更加明確化，可以看作是ATDD的實(shí)例化，即列出用戶故事所可能遇到的應(yīng)用場(chǎng)景，而且將這種應(yīng)用場(chǎng)景的表達(dá)方式規(guī)定為GWT格式，即：

BDD再往前推進(jìn)一步，就是需求實(shí)例化（Requirements By Example，RBE），更加明確需求的具體表現(xiàn)。還是以上面用戶故事為例，可以建立類似下列內(nèi)容的需求實(shí)例化。

需求越明確，用戶、產(chǎn)品經(jīng)理、開發(fā)與測(cè)試等之間的理解就越一致（on the same page），更不產(chǎn)生偏差和誤解，有利于開發(fā)和測(cè)試的工作?；赗BE，開發(fā)人員寫產(chǎn)品的代碼，測(cè)試人員可以獨(dú)立寫測(cè)試的代碼，產(chǎn)品經(jīng)理的工作也會(huì)變得輕松，不需要太多的解釋、不需要回答開發(fā)和測(cè)試的各種問題。

• 從需求角度看，BDD和需求實(shí)例化比較徹底地明確需求，統(tǒng)一用戶、產(chǎn)品經(jīng)理、開發(fā)與測(cè)試等認(rèn)識(shí)，讓大家處在一個(gè)層面上，使研發(fā)工作更高效。

• 從測(cè)試角度看，需求即測(cè)試，產(chǎn)品的需求就是測(cè)試的需求，需求可以被執(zhí)行，即一步到位，將需求變?yōu)樽詣?dòng)化測(cè)試腳本，開發(fā)出來的功能特性隨時(shí)可以被自動(dòng)驗(yàn)證。

TDD一改以往的破壞性測(cè)試的思維方式，測(cè)試在先、編碼在后，更符合“缺陷預(yù)防”的思想。這樣一來，編碼的思維方式發(fā)生了很大的變化，編寫出高質(zhì)量的代碼去通過這些測(cè)試，在進(jìn)行每項(xiàng)設(shè)計(jì)、寫每一行代碼時(shí)都要想想用戶的真實(shí)需求、應(yīng)用場(chǎng)景和一些例外等，確保實(shí)現(xiàn)的功能特性符合預(yù)期，并具有健壯性。測(cè)試，也從以前的破壞性的方法轉(zhuǎn)移到一種建設(shè)性的方法中來。在這種積極心態(tài)的影響下，開發(fā)人員的工作效率和產(chǎn)品的質(zhì)量都會(huì)有顯著的提高，真正實(shí)現(xiàn)“質(zhì)量是內(nèi)建的（Quality is built in）”的目標(biāo)。

感謝各位的閱讀，以上就是“TDD、ATDD、BDD&RBE分別是什么”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)TDD、ATDD、BDD&RBE分別是什么這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！