TDD VS BDD：REST服務

Question

我對TDD和BDD都感到困惑:) TDD和BDD在以下每個方面有何不同？

1. 發展：測試用例第一，開發遵循下一

2. RestService（HTTP）：不要讓其他電話？如果是這樣，

   a）我們只使用模擬對象返回硬編碼的json嗎？

   b）如何處理REST呼叫失敗？我們也應該有這樣的測試案例嗎？

尤其是對於第2項，我搜索了很多文章，但是找不到關於如何處理其他調用的示例（代碼）方法。

Answer 1

儘管BDD和TDD都在測試第一次開發中使用，但它們沒有可比性。

BDD不僅僅是用類似英語的語法編寫測試，例如，奇異果。 BDD（也稱爲ATDD-Acceptance Test Driven Development）以開發人員，QA和設計人員（例如業務人員和交互設計人員）爲起點，共同共同理解所提出的解決方案。通常使用示例來說明行爲，也稱爲按示例規範。

我發現抽象思維的一個有用的方法是區分你所做的事（抽象的，高層次的策略）和你如何做（具體的，低層次的細節）。每一個具體的細節都是爲了實現更高層次的政策。當你看到具體的事情時，確定它所服務的政策是有益的。

通過示例的規範可用於創建高級驗收測試，測試應用程序的功能，即其行爲。

單元測試用於測試應用程序如何實現解決方案，即測試相應的消息是否在適當的時間發送給其協作者/依賴項。

標準TDD週期的階段是紅色，綠色，重構。在綠色環保階段，您的目標是儘可能快地通過測試，通過鉤子或欺騙手段 - 編寫醜陋，無組織的代碼是可以接受的。一旦測試通過，您可以重構代碼以使其更具可讀性/可更改性。

類似地，在BDD/ATDD循環中，您有Red，Green，Refactor。在BDD綠色階段，只需通過驗收測試。您所編寫的所有代碼都可以存在於測試本身內。在BDD的重構階段，您將測試代碼提取到生產代碼中。您可以使用TDD指導提取。

因此，對於給定的BDD驗收測試，您可能有多個TDD測試。

關於如何測試REST調用，讓我們回到抽象的前提 - 區分我們做什麼和如何做到這一點。

調用REST服務是一個具體操作。它滿足的策略可能是提供一個模型對象列表。

假設您正在實施的用例是邀請朋友共進午餐。部分用例責任是從服務器獲取朋友列表;它不關心服務器如何找到朋友。

您的BDD測試將處理獲取朋友列表，挑選朋友和完成邀請。您的BDD測試不會擔心實際進行REST調用。

當您使用TDD實現處理與服務器通信的類時，您可以進行從遠程數據源（即服務器）檢索JSON的測試，並確保將JSON正確解析爲User模型對象。您也可以進行測試，以覆蓋數據源對錯誤的響應等。

在您實際進行REST調用時，在實現使用REST與後端服務器通信的遠程數據源時，我會將它分類爲集成測試，因爲您正在測試與您不控制的組件（即實際的後端服務器）的集成。集成測試只需確認服務器以您的應用預期的格式返回JSON數據，或者在適當的時候返回錯誤。

Answer 2

BDD實際上是derived from TDD，所以它有點混淆並不奇怪！ BDD與TDD完全相同（或者如果您是爲整個系統執行的話，ATDD），但沒有「測試」一詞。事實證明，這可能非常強大。

特別是，它可以讓開發人員與非技術業務人員討論系統應該做什麼。即使是技術專家，您也可以使用它來進行關於類應該做什麼的對話或者應該執行的代碼模塊。

因此，在您的REST服務的示例中，您可以想象我是開發人員，而且您是知道REST服務應該做什麼的專家。

我：它應該怎麼做？
您：它應該讓我讀一條記錄。
Me：太好了！你能給我一個記錄的例子嗎？
您：我有一個在這裏...
我：有其人不應該能夠讀取記錄任何上下文？
你：當然，如果他們沒有權限。

...

我：好了，所以我所做的閱讀，讓我們做更新。你能舉一個典型的更新的例子嗎？
你：你在這裏。
我：太棒了，你希望它只是成功或失敗的反應。 應該失敗嗎？
你：當然。該記錄顯示了上次更新的時間。如果其他人在此期間已經更新了它，則在您提交時應該失敗。

因此，您看到您可以使用BDD來探索各種場景，包括REST服務周圍的場景。訣竅是問，「你能給我一個例子嗎？」然後你會得到一個具體的例子，然後你可以自動化，如果你想。對話有助於我們尋找其他我們可能錯過的示例和場景。

不要使用BDD工具爲技術人員實現自動化！像Cucumber，JBehave等BDD工具使用真正的英語，比代碼更難重構。如果你只是在做一些像REST服務一樣的東西，請使用JUnit，NUnit等。您可以在評論中添加「給定，當時，然後」，或者製作一些DSL。

所以，現在你可以看到你的REST調用失敗，如果我編碼它，我有這樣一個例子：

我：所以，這個呼叫失敗...你能給我一個例子？
你：當然，如果你訪問一個被刪除的記錄，它會失敗。
Me：給我一個可能被刪除的記錄的典型例子嗎？
您：我們以前使用的是好的。
我：好的，有沒有我們不應該刪除記錄的情況？
您：是的，如果它已經被公佈......

等等

你可以看到整個，我真的不使用單詞「測試」。測試是BDD中的一個很好的副產品。它更多地用於需求的探索和規範。 BDD中的對話是其中最重要的部分。

找到使用BDD for REST的示例很棘手的原因首先是因爲REST故意簡單並且通常不會有很多行爲，其次是因爲BDD的場景通常並未在其實現方面表達出來，而是關注服務或系統提供的價值（「讀取記錄」）。

TDD和ATDD是完全一樣的，如果他們做得很好。關於示例和場景的談話要比談論測試更容易。