某公司遇到的困境

之前在某公司咨詢的時(shí)候，遇到了這種場(chǎng)景，公司想做敏捷轉(zhuǎn)型，然后自己找了很多敏捷相關(guān)的實(shí)踐，這其中就包含BDD。 由于之前公司之前并沒有自動(dòng)化的測(cè)試，所以在討論自動(dòng)化的實(shí)施的時(shí)候，聽說BDD這個(gè)敏捷實(shí)踐很不錯(cuò)，就專門花重金找了一個(gè)測(cè)試專家搭建了一套BDD的測(cè)試框架。 然后同樣又花重金請(qǐng)人教會(huì)了他們測(cè)試人員如何去運(yùn)用這套BDD框架寫自動(dòng)化測(cè)試用例，甚至從外面招聘有BDD自動(dòng)化經(jīng)驗(yàn)的人。做完了所有的準(zhǔn)備工作之后，大家對(duì)產(chǎn)品瞬間就有信心了，于是就開始了他們BDD之旅。

做法很簡(jiǎn)單，就是開發(fā)去做卡，做完之后就交給測(cè)試去測(cè)試，最后由測(cè)試去寫B(tài)DD的測(cè)試。所有的BDD的測(cè)試都是端到端的測(cè)試，大家做了很多這種端到端的自動(dòng)化測(cè)試，隨著時(shí)間的推移，這種自動(dòng)化越來越多，大家發(fā)現(xiàn)好像BDD的測(cè)試框架好像并沒有像預(yù)期的那樣發(fā)現(xiàn)很多問題，幫助他們改善質(zhì)量。相反的，維護(hù)這些測(cè)試用例卻花費(fèi)了大量的時(shí)間。由于BDD是公司的領(lǐng)導(dǎo)層想推行的實(shí)踐，大家也不好去反對(duì)。慢慢的BDD變成了一種形式，花了很多時(shí)間去寫，但是卻沒有達(dá)到預(yù)期的效果。??

問題出在哪？

我們?cè)趪L試運(yùn)用某個(gè)敏捷方法的時(shí)候，至少需要想考慮清楚兩方面，第一個(gè)是這個(gè)敏捷方法的使用場(chǎng)景，第二個(gè)是這個(gè)敏捷方法能夠帶來哪些價(jià)值。

BDD的概念

基于上面所提出的問題，我們首先來看下一下BDD的概念：?

Behavior-Driven Development (BDD) is a set of software engineering practices designed to help teams build and deliver more valuable, higher quality software faster. It draws on Agile and lean practices including, in particular, Test-Driven Development (TDD) and Domain-Driven Design (DDD). But most importantly, BDD provides a common language based on simple, structured sentences expressed in English (or in the native language of the stakeholders) that facilitate communication between project team members and business stakeholders.

從這中間我們可以提煉出一下幾個(gè)關(guān)鍵點(diǎn)：1）行為驅(qū)動(dòng)開發(fā)是一個(gè)軟件工程的實(shí)踐，能夠幫助團(tuán)隊(duì)快速構(gòu)建和交付更多價(jià)值和質(zhì)量的軟件產(chǎn)品。? ?2）BDD提供了一種通用的，簡(jiǎn)單的，結(jié)構(gòu)化的描述語言，能夠很方便讓項(xiàng)目成員和業(yè)務(wù)干系人非常順暢的溝通需求。

從中我們可以看到BDD的價(jià)值在于能夠溝通與協(xié)作，能夠把利益關(guān)系人、交付團(tuán)隊(duì)等不同方面的項(xiàng)目相關(guān)人員集中到一起，形成共同的理解，共同的價(jià)值觀以及共同的期望值。這個(gè)是BDD的價(jià)值所在。

BDD到底應(yīng)該怎樣解讀

那接下來我們來分析下BDD到底適合什么樣的場(chǎng)景呢？ 我們可以從他的價(jià)值來進(jìn)行分析，如果利益關(guān)系人溝通完全沒有障礙，那根本不需要運(yùn)用BDD，這很容易理解，比如簡(jiǎn)單的一次性的項(xiàng)目，或者業(yè)務(wù)比較輕量，重在技術(shù)方面的項(xiàng)目，大可不必運(yùn)用BDD，因?yàn)樵谶@種項(xiàng)目下，項(xiàng)目關(guān)系人對(duì)整個(gè)項(xiàng)目也不會(huì)存在理解上的問題。相反的，業(yè)務(wù)復(fù)雜、團(tuán)隊(duì)成員較多的項(xiàng)目，溝通成本高，BDD有可能就很有必要。

還有一個(gè)誤區(qū)，上面的例子也提到了，把BDD當(dāng)成僅僅是測(cè)試相關(guān)的。其實(shí)BDD并只是關(guān)于測(cè)試，它是一個(gè)敏捷方法，是一種協(xié)作方式，更多的BDD應(yīng)該關(guān)注的是業(yè)務(wù)也不是技術(shù)。我們可以用以下的圖來表示

另外一個(gè)很大的誤區(qū)在上面例子中也有所體現(xiàn)，在實(shí)施的時(shí)候他們僅僅只是把BDD定義為端到端的自動(dòng)化測(cè)試，這個(gè)是完全不對(duì)的，BDD的自動(dòng)化可以是端到端的自動(dòng)化，可以是API測(cè)試，可以是單元測(cè)試，甚至可以是他們的結(jié)合體，比如在BDD的設(shè)計(jì)中，用API去創(chuàng)建數(shù)據(jù)，然后再寫端到端的測(cè)試。

其實(shí)對(duì)于敏捷來說，不管我們運(yùn)用哪些時(shí)間，BDD？TDD？Code Review? 還是別的，我們需要基于這些具體的實(shí)踐，去分析這些實(shí)踐能給我們帶來哪些價(jià)值。不能盲目的用。

如果通過分析發(fā)現(xiàn)BDD對(duì)于項(xiàng)目沒有價(jià)值，那么勇敢的提出來，“不要再用BDD了” 。

具體BDD應(yīng)該怎樣正確的去做，我在以后的簡(jiǎn)書里面會(huì)提到，這里就不再累贅了。