BDD故事風格

我們正在嘗試使用BDD開發SOA系統，使用Scrum，並且已經遇到了兩種生成故事的方法。BDD故事風格

Approach 1 
    Given Specific Message Type is available 
    And Specific State exists 
    When the Message is processed 
    Then expected resulting state exists 

Approach 2 
    Given a Specific state exists 
    When Specific Message Type is processed 
    Then expected resulting state exists

幾乎沒有任何示例應用於SOA系統。我希望有任何這方面的經驗或任何有關每種方法的後果的見解。

我們針對的是declarative rather than imperative stories。到達第一個的消息有一點必要的感覺，但我對第二個方法沒有充分的信心，因爲它似乎沒有考慮到SUT的事件驅動性質。

來源

2014-03-13 Martin Spamer

我投票結束這個問題作爲題外話，因爲[項目管理現在堆棧溢出主題]（//meta.stackoverflow.com/questions/343829/is-stack-overflow-an-適當的 - 網站對問，關於項目管理，問題/ 343841＃343841）。請在[SoftwareEngineering.SE]（// softwareengineering.stackexchange.com/）和[ProjectManagement.SE]（// pm.stackexchange.com/）上提出這些問題。（不幸的是，這個問題太舊，無法遷移。） – robinCTS

故事的目的是與您的客戶進行溝通，所以無論什麼風格都會促進這個目標是最好的 - 而且這種差異會因團隊而異。我可能更喜歡'發生一些商業事件'而不是你的建議，但我不瞭解你的團隊！謹防試圖找到一個「一刀切」的模板，使用任何最適合每種情況的通信方式。敏捷的核心是適應能力 - 嘗試一種風格，如果它看起來沒有工作，可以自由適應。

來源

2014-03-13 15:00:46

我想填補我的'工具箱'不採用'一刀切'的一切，因此是一個懸而未決的問題。 –

每當我製作一個庫或服務時，我經常發現提供一個服務用戶可能需要的場景類型的例子很有用。因此，例如：

鑑於服務器有關Lieumoney兄弟
風險限額的信息和我們是從這些限制2米$
當我們處理的是帶我們到$ 1百萬那些限制
然後EOD訂單我們與Lieumoney兄弟的地位應該是琥珀。

該消息的實際內容然後可以反映與那些特定總和和特定交易對方的交互。您可以將其用於許多不同的域，並且您的方法將取決於域以及該域的消息是否可用。在上述交易數百萬美元的例子中，具有特定交易對手的風險信息可能是有價值的，如果這是狀態，則值得單獨調用。例如，如果您購買小兔子，這可能不那麼重要。

鑑於「Rotweiller寵物有限公司」當我們要求系統訂購15只兔寶寶
那麼就應該把與「Rotweiller寵物有限公司」的訂單交易兔寶寶$ 2比誰都
便宜。

沒有具體的例子就很難討論這個問題。然而，即使這些場景的底層自動化直接與API對話，並且沒有真正針對寵物或Lieumoney交易的具體內容，您也許可以看到如何提供這些場景作爲如何使用API的文檔。

來源

2014-03-25 00:15:08 Lunivore

回答

相關問題