閱讀225 返回首頁    go 阿裏雲 go 技術社區[雲棲]


《Cucumber:行為驅動開發指南》——1.2 行為驅動開發

本節書摘來自異步社區《Cucumber:行為驅動開發指南》一書中的第1章,第1.2節,作者:【英】Matt Wynne , 【挪】Aslak Hellesy著,更多章節內容可以訪問雲棲社區“異步社區”公眾號查看

1.2 行為驅動開發

行為驅動開發(Behaviour-Driven Development,BDD)1建立於測試驅動開發的基礎之上,它標準化了那些優秀TDD實踐者的良好習慣。優秀的TDD實踐者以自外向內的方式開發軟件,最初他們會編寫一個失敗的客戶驗收測試,該測試從客戶的視角描述係統的行為。作為BDD實踐者,我們細心編寫驗收測試,作為所有團隊成員都能讀懂的實例。我們使用這個編寫實例的過程來獲取業務人員的反饋,以便在開始實現軟件之前,我們就知道自己是否是在編寫正確的軟件。在此過程中,我們會主動開發一種共享的通用語言(ubiquitous language)來描述和討論我們開發的係統。

1.2.1 通用語言
正如Eric Evans在他的《領域驅動設計》[Eva03]一書中所描述的,很多軟件項目都受過團隊中領域專家和開發人員之間低質量溝通之苦:

“如果一個項目中的語言是支離破碎的,那麼這個項目就麵臨著嚴重的問題。領域專家使用他們的行話,技術團隊成員則擁有自己的、專門從設計角度討論領域的語言……由於這種語言方麵的分歧,領域專家描述他們的需求的時候非常模煳。開發人員努力嚐試理解一個全新的領域,卻隻能得到模煳的結果。”

通過整個團隊的自覺努力,項目涉及的所有人都能理解和使用的一款通用語言就會出現。如果整個團隊在所有交談、文檔及代碼中一致地使用這種語言,就不需要再花精力去翻譯各自的不同方言,理解錯誤的概率也因此大大地降低了。

Cucumber為存在語言分歧的雙方提供了可以會合的場所,從而促進了通用語言的發現和使用。Cucumber測試直接與開發人員的代碼交互,同時它們又是用一種利益相關人能夠理解的中間語言編寫的。通過一起編寫測試的方式,即協作描述(specifying collaboratively),團隊成員不僅確定了下一步要實現的行為,也學會了怎樣用一種大家都能理解的通用語言描述這種行為。

如果我們在開發開始之前就編寫驗收測試,就可以在錯誤的理解滲入代碼之前發現並消滅它們。

1.2.2 實例
Cucumber之所以能從大量的測試工具中脫穎而出,是因為它在設計時有一點非常明確,就是確保團隊中的任何人都能夠很容易地閱讀或編寫驗收測試。這符合驗收測試的本質——作為一種交流和協作的工具。Cucumber測試的易讀性把利益相關人吸引到協作過程中來,幫助大家探索並真正理解他們的需求。

下麵是一個Cucumber驗收測試的實例:

Feature: Sign up

 Sign up should be quick and friendly. 

 Scenario: Successful sign up

  New users should get a confirmation email and be greeted
  personally by the site once signed in.

  Given I have chosen to sign up

  When I sign up with valid details
  Then I should receive a confirmation email
  And I should see a personalized greeting message

 Scenario: Duplicate email

  Where someone tries to create an account for an email address
  that already exists.

  Given I have chosen to sign up
  But I enter an email address that has already registered 
  Then I should be told that the email is already registered 
  And I should be offered the option to recover my password

注意測試是如何描述為特定場景下我們期望的係統行為的實例(example)的。類似的實例能夠強有力地幫助人們在係統被構建之前就將其形象化,效果通常超出大家的預期。任何團隊成員都能閱讀這樣的測試,然後說出該測試是否反映了他對係統行為的理解,這樣的測試也許還會激發他們進一步的思考,從而發現其他你未曾考慮的場景。Gojko Adzic的《實例化需求》一書包含了很多這方麵的案例研究,案例中涉及的團隊發現了實例的優點並將其充分利用。

以這種風格編寫的驗收測試已經不僅僅是測試了,它們是可執行的規格說明(executable specification)。

最後更新:2017-06-05 11:32:17

  上一篇:go  RDS SQL Server - 專題分享 - 巧用執行計劃緩存之索引缺失
  下一篇:go  《Cucumber:行為驅動開發指南》——第1章 為何使用Cucumber 1.1自動化驗收測試