持續集成和驗收測試驅動開發

我有一個與驗收測試驅動開發（ATDD）相關的問題。根據該過程，我通過驗收測試（端到端測試）開始每個功能。我承諾進行這些測試，並且如預期那樣失敗。問題在於我應該以某種方式區分由於功能不完整而導致失敗的驗收測試和由於一些迴歸而失敗的驗收測試。使用ATDD組織CI過程的最佳做法是什麼？持續集成和驗收測試驅動開發

來源

2013-02-22 Markus

你可以標記帶屬性的小黃瓜裝置 - 你可能有一個不完整的測試屬性（如果你使用的是基於小黃瓜的ATDD框架，如SpecFlow或黃瓜） – levelnis 2013-02-22 10:58:42

沒有親身體驗過它，但我在一位軟件公司向我展示了他們如何開發軟件。他們在Selenium中寫了驗收測試，他們在名字中使用sprint ID作爲約定。這樣他們可以很容易地看到失敗的測試是新的還是舊的。你是這個意思嗎？（PS：很好的問題，驚訝的是有這麼少的迴應） – bas 2013-02-23 20:37:41

尚未實現的測試不應在CI中運行。 CI測試的重點是捕捉迴歸。捕捉「尚未完成」的問題會造成紅色構建「正常」並被忽略的情況。這是可能的最糟糕的結果。

有很多方法可以做到這一點，最好的方式取決於你的上下文。最簡單的方法是首先編寫驗收測試，但不要在驗證通過之前檢查它（即實現該功能）。

來源

2013-02-24 22:06:42 tallseth

好的答案。至於沒有登記，另一種選擇是檢查測試，但以某種方式禁用它們。大多數X-unit測試框架都有某種方式告訴測試框架應該忽略測試。 – Petrik 2013-02-24 22:24:56

不完全同意這一點。並非所有驗收測試都可以在本地執行，以檢查它們是否通過。生產環境需要運行它們。這並不總是可用的。此外，一些開發人員可能會在同一個故事中工作，他們都不會看到他們在故事中的進展，也就是驗收測試可以顯示的進展。 – Markus 2013-02-25 06:08:20

如果您不能在本地運行驗收測試，那是一個***嚴重的問題***！我會努力解決這個問題。 – tallseth 2013-02-25 15:40:45

持續集成和驗收測試驅動開發

回答

相關問題