Given..When..Then用戶故事示例適用於REST API

敏捷開發人員使用這種風格開發API嗎？Given..When..Then用戶故事示例適用於REST API

有什麼不錯的例子嗎？

到目前爲止，我在互聯網上找到的例子很少（同樣適用於「The Cucumber book」的第12章）。我在github中檢查了包含「Given」字樣的.feature文件，結果太多了，它們都與我的用例無關。我可以以更復雜的方式搜索以實現我的目標嗎？

來源

2016-11-02 Crone

我不確定爲RESTful API定義前置條件和後置條件是否有用。 REST通過底層協議定義其可能的操作。大多數情況下，這是HTTP（POST，GET，PUT，DELETE，PATCH，...）上的一些可協商的表示格式（純文本，文本/ html，應用程序/ json，應用程序/ xml，...）。一個發展良好的內容類型也可以支持RESTful客戶端執行進一步的操作（即HAL，ATOM，...），從而使得當時的文檔冗餘。 –

@Roman Vottner我不明白你的觀點，小黃瓜將用於以BDD方式開發API。驗收測試將按照「給定的條件，當客戶做這件事時，那麼迴應應該是這樣」來寫。這不是一種友好的開發方式嗎？編輯：是因爲我寫了「描述API」而不是「開發API」？如果是的話，我的意思是開發 – Crone

那麼，實際問題更多地與測試相關，而不是生產性代碼？如果是這樣，我誤解了你的實際問題。我以爲你正在尋求一些WADL，Swagger ......替代品（我不是很喜歡它們，因爲它們違背了基本的REST理念）來自動測試REST API。 –

我解釋你的問題，就好像你正在尋找複雜的例子，可以聲稱這是做到這一點的方法。

從我的角度來看，黃瓜書第12章中的例子可能看起來微不足道。但我認爲他們可能太過技術性。我不確定產品所有者或類似的非技術人員能夠驗證它們。

我在這裏指出的是，場景應儘可能非技術性，因此包含最低限度的技術細節（如果有的話）。這將導致非技術人員可以驗證的內容。您將能夠討論解決您的業務問題而不是技術細節。對於業務可能重要或不重要的詳細信息。在BDD經常運行的級別上，它可能不是很有趣，知道這是使用REST實現還是使用其他方法。

如果您正在測試您正在尋找的其他工具，可能比任何BDD工具更適用並且可能更易於使用。但是，嘗試瞭解您最終將解決的業務問題時，這些工具可能不易於使用討論基礎。

來源

2016-11-02 18:27:53

我在尋找完整的例子來看看它是如何完成的。如果完全是這樣。我同意用戶故事不應該是技術性的。我的目標不是測試。即使是基於測試的TDD和BDD也在開發方法。但我不一定想要嚴格執行BDD，更像是一種構建API的新方法。 – Crone

Given..When..Then用戶故事示例適用於REST API

回答

相關問題