如果有一個項目具有作爲構建機器上的構建過程的一部分執行的測試，如果一組測試失敗，整個構建是否會失敗？
回答這個問題時應該考慮什麼？這些測試失敗了嗎？促使這個問題如果失敗的測試會使連續構建失敗？
背景資料：
目前我的工作有NUnit測試，完成作爲構建過程的一部分，我們的cruise control .net構建機器上執行一個項目。
該項目用於設置，以便如果任何測試失敗，構建失敗。推理是如果測試失敗，這意味着產品不能正常工作/不完整/項目失敗，因此構建失敗。
我們已經添加了一些測試，雖然他們失敗了，但他們對項目並不關鍵（詳情見下文）。所以如果這些測試失敗了，那麼這個項目並不是完全失敗，我們仍然希望它能夠建立。
其中一個通過的測試驗證不正確的參數導致異常，但測試未通過的是檢查所有允許的參數是否爲而非導致異常的測試。所以班級拒絕所有無效的案件，但也有一些有效的案件。這對於這個項目來說並不是問題，因爲被拒絕的有效論據是應用程序不會依賴的邊緣案例。
如果它以任何方式可行，那就去做吧。它大大減少了broken-window-problem：
在沒有（可見）缺陷的系統中，引入一個小缺陷通常被認爲是一個非常糟糕的主意。因此，如果你有一個綠色狀態的項目（沒有單元測試失敗），並且你介紹了第一個失敗的測試，那麼你（和/或你的同伴）將會被激勵來解決這個問題。
如果在另一方面存在已知失敗的測試，那麼只添加另一個破壞的測試被視爲保持現狀。
因此，您應該始終努力保持所有測試運行（而不僅僅是「大多數」）。將每一次失敗的測試都視爲失敗的原因，對於實現這一目標有很長的路要走。
如果單元測試失敗，某些代碼的行爲並不像預期的那樣。所以代碼不應該被釋放。
雖然您可以爲構建測試/ bug修復目的。
如果您覺得某個案例足夠重要，可以編寫測試，那麼如果該測試失敗，則該軟件將失敗。基於這一點，是的，它應該認爲構建失敗並且不會繼續。如果你不使用這種推理，那麼誰來決定哪些測試不重要？ 「如果失敗就沒關係，但如果失敗則不是」？失敗就是失敗。
我認爲像你這樣的好設置應該總是成功構建，包括所有傳遞的單元測試。
就像Gamecat說的那樣，構建本身是成功的，但是這段代碼永遠不會投入生產。
想象一下你的團隊成員介紹，其中一個單元測試（這總是失敗）覆蓋代碼中的錯誤之一。它不會被測試發現，因爲您允許一個測試總是失敗。
在我們的團隊，我們有一個簡單的策略：如果所有測試沒通過，我們不要去生產的代碼。對於我們的項目經理來說，這也是一個非常簡單的理解。
在我看來，它真的取決於你的單元測試，如果你的單元測試真的是單元測試（就像他們應該=>「參考無盡的書籍）」） 然後構建應該失敗，因爲某些東西不應該像......
但是大多數情況下（不幸地經常看到），在如此多的項目中，這些單元測試只覆蓋了一些「邊緣」和/或集成測試，然後構建應該繼續 （是的，這是一個主觀的答案;）
簡而言之： 你知道單元測試很好：失敗; 其他：建立在
真正的問題是在你失敗的測試。你不應該在可以失敗的情況下進行單元測試，因爲這是一個邊緣情況。確定邊緣情況是否重要 - 如果不是，則刪除單元測試;如果是，然後修復代碼。
就像其他一些暗示的答案一樣，當單元測試失敗時它絕對是代碼味道。如果你住用鼻子聞，那麼你就不太可能發現下一個問題
所有的答案都已經很大了，這裏是我決定的事情：
讓測試（或者如果需要進行分割一個失敗的測試）NUnit忽略不重要（我問這個問題後我記得這個功能）。這允許：
我認爲這是最好的折衷辦法，迫使人們修復試驗，但不一定馬上（但他們必須捍衛現在不是修復它自己的決定，因爲每個人都知道他們做到了）。
我實際做了什麼：修復了破損的測試。
+1：「附帶案件」不是理由。修復代碼或修復測試。 – 2009-01-30 14:09:39