Behavior-Driven Development概念思考

這篇文章建立在對BDD有初步認識後產生的一些理解和思考。完全不知道BDD的同學建議去google一下先。

 

BDD的定義：

Behavior-Driven Development is about implementing an application by describing its behavior from the perspective of its stakeholders.

這裡需要注意兩點：

stakeholders：BDD defines a stakeholder as anyone who cares about the work we are undertaking, whether they are the people whose problem we are trying to solve—known as the core stakeholders—or the people who are going to help solve it—who we call the incidental
stakeholders.

From a BDD perspective, there is no such thing as a nonfunctional requirement, just a feature with an incidental stakeholder. Even the people in the delivery team are stakeholders.

behavior：即從stakeholders的角度，看到的程式的行為。

 

BDD的作用：

其實BDD和agile是緊密相關的。在agile中，我們使用BDD測試作為acceptance test。也就是說，在一個sprint中，每一個程式員分配到一個任務後，將有一個BDD case與之對應，作為程式員是否完成該task的驗收標準。

從這一點來說，BDD就是TDD的發展：

在一個sprint開始時，就有一個BDD case存在，開發人員將把這個case作為目標，在sprint中努力讓該case通過。這就是典型的TDD，只不過同時結合了BDD一些思想，即在一開始，需要實現的test case到底是什麼。

事實上，BDD出現的背景，就是開發人員在TDD時，總是不清楚到底該將一個什麼樣的test case作為自己TDD開發需要實現的目標。

而BDD簡單的回答了這個問題：讓stakeholders用一個test case告訴你，你的具體目標是什麼。同時強調了，每一個開發目標都應該是系統的behavior的體現。

 

這裡有三條BDD的原則，可以讀讀來加強理解：

We sum this up using the following three principles of BDD:
Enough is enough

Up-front planning, analysis, and design all have a diminishing return. We shouldn’t do less than we need to get started, but any more than that is wasted effort. This also applies to process automation. Have an automated build and deployment, but avoid trying
to automate everything.

這一點顯然秉承了agile的一貫原則：不做多餘的事兒。

Deliver stakeholder value

 If you are doing something that isn’t either delivering value or increasing your ability to deliver value, stop doing it, and do something else instead.
It’s all behavior

 Whether at the code level, the application level, or beyond, we can use the same thinking and the same linguistic constructs to describe behavior at any level of granularity.

上面的兩點則是BDD的核心思想。

 

BDD的開發過程：

下面來看看加入BDD後，開發的過程。

• 為BDD case規定統一的文法

BDD的精髓之一就是使用一種所有stakeholders都可以理解的統一語言，同時也一定是一個很nature的語言，來書寫test case。

但是，這並不意味著可以隨意的在BDD case中想寫什麼寫什麼。BDD case中的文法必須經過所有stakeholders討論並達成一致。

討論時，必須讓業務人員和技術人員坐在一起。因為業務人員認為合理的BDD case的寫法，技術人員在實現時可能會很困難。而技術人員提出的實現，也可能不能滿足業務人員的需要。

 

因此，我們需要嚴格規定BDD 的文法，並形成一個統一的正式的文檔，供所有stakeholders參考。

它看起來應該是下面的樣子：

 

Scenario: <Component>,<Asset>,<Function>,<Test Type>

Given load complete

When there is a input file which contains <value>|<valuelist>

Then check <output> “does not contain”|”contains”  <propvalue>|<propvaluelist>

這裡規定了在每一個step中，可以出現的內容。其中可變的部分為symbols。例如given step只能是“load complete”，是不可變的。when step則只能是出現了一個input file，該input file中包含了一些指定的值。

同時需要對step中出現的<Component>等symbol做出詳細的解釋：

<Component>=CL3|PORTFOLIO

<Test Type>=Smoke|Regression|<Bug> <Test Type>

<function>=Benchmarks|RICRules|Denormalistion etc <Function>

<asset>=Equity|Option|Fixedincome|Organisation etc <Asset>

<value> = <be>.<field>:<value>

<valuelist> =” <be>|<field>|<value>”|\n<Propvaluelist>

etc

 

一旦達成一致，BDD case就必須嚴格使用規定的文法，開發人員也只會在BDD架構中支援規定的文法。除非有需求表明需要擴充已經使用的文法。

 

• 一個BDD case應包含的內容

在瞭解了BDD的基本知識後，我們知道一個BDD case稱為一個story，它的的組成部分是：

A title

A narrative

acceptance criteria：實際就是一個一個的scenario。

 

因此第一個基本問題就是：如何定義一個story

首先feature和story的區別

Many people use the words feature and story interchangeably, but there is a subtle difference. A feature is something that delivers cohesive value to a stakeholder.A story is a piece of demonstrable functionality that shouldn’t take more thanafew
days to implement. So, the feature is more useful fromthe point of viewof the stakeholder, and the story is more useful fromthe point of viewof the team delivering the feature.

也就是說，提需求的人提出一個feature，需要將feature分成一個或多個story。而每個story需要的effect應大致相同。

 

那麼每個scenario又該如何書寫呢？

每一個scenrio由step組成，通常是：

Given

When

Then

For the setup, the givens, it doesn’t matter how we get the world into a known state. 因此Given的內容應該是，要運行這個scenario，要求系統或程式處於什麼狀態。這裡已經強調了，Given並不關心如何達到這個狀態。

What matters is that the event steps have no idea how this happened and interact with the application in exactly the same way the stakeholder would. 因此Event是一個事件。

Similarly, it doesn’t matter how you verify the outcomes, just that you do.

 

我們舉這樣一個例子來更好的理解scenrio：一個拷貝檔案的程式，當input folder中出現檔案時，將檔案上傳到FTP server，同時在log中記錄一行。

因此這裡我們需要兩個scenrio：

Given application is running  --如前面所說，Given並不關心如何啟動application，僅是表明當前的狀態。在背後實現的時候，這句可以意味著啟動程式，也可以僅僅是驗證程式正在運行。

When put a file to input folder

Then find this file on FTP server --不關心如何驗證

 

Given application is running

When put a file to input folder

Then find a record in log file 

 

第二個基本問題：誰是寫BDD case的主體？

BDD case毫無疑問是用一種通用的，易於所有stakeholders理解的，自然的，自訂的語言寫成的。但這並不意味著，BDD case應該由業務人員或客戶完成。

也就是說，一個BDD case， 即story涉及的內容，應該由stakeholders一起討論完成。例如，客戶提出，並和所有人商議確定在一個story中應完成的功能。

而具體的scenario，則由測試人員完成。由於採用事先定義的自然語言，所有stakeholders都可以理解，監督story完成的內容。

scenario應具備兩個特徵：即能被所有人理解，又能容易的被自動化運行。

所以這裡隱含的意思是：雖然採用了所有人都可以理解的自然語言，但是書寫test case仍然可以被理解為一個“技術活”。它仍然需要有測試經驗，有技術背景的人員來完成。

否則極有可能出現業務人員寫出一些看上去很合理，很自然，但實際卻難以實現，或概念模糊，或測試內容不清，或覆蓋邏輯不全面的test case。

因此可以說：acceptance criteria are “owned” by the tester 而story “owned” by stakeholders.

第三個基本問題：寫BDD case的時機：

因為BDD是測試驅動開發TDD的更進階的階段，所以BDD case必定要先於程式碼完成。但並非是在確定需求時就要完成。

it does need to happen before we do anything that requires an understanding of “done,” such as scheduling work during iteration/sprint planning.

• 開發人員將scenario自動化

開發人員需要使用JBehave或Specfolw這樣的工具，將在BDD case中使用的統一語言翻譯成實際的test case，並實現自動運行。

這步更多的是一些技術方面的問題，就不多說了。

• 開發人員開始編寫代碼，使BDD test case通過

如前面所說，在做一個反覆項目計劃時，就應該寫好BDD case。當一個迭代開始時，運行這個case，很顯然會失敗。開發人員需要做的就是編寫代碼，使case成功。通常這個過程稱為：red/green/refactor

一旦case通過，就意味著代碼開發完成。而代碼則end up with just enough software to make the scenario work。

最後是關於BDD case和UT的思考

一個BDD case可能實際上就是一個UT，即單元測試：例如當一個scenario測試的是，當一個目錄下出現txt檔案時，歸檔。如果archive功能僅由一個class完成，那毫無疑問這就是一個UT。

如果我們已經有UT了，那就是重複測試。更何況BDD架構都是基於JUnit，NUnit這種UT測試架構做的，那麼無論是使用技術和測試內容上都完全一致了。

在我看來，BDD的測試範圍是很難規定的：有時scenario就是一個UT，而更多時候是整合測試。因為scenrio描述的是程式的behavior，一個behavior通常會涉及多個類，甚至多個組件。

而且tester，即scenario的編寫人員，並不知道背後涉及的代碼有多少。

因此一個可行的辦法是，開發人員在編寫代碼時，如果發現scenario涉及的就是一個UT的話，就不再另外編寫class對應的UT了。