我正在開發一個項目，其中包含大量未覆蓋測試的遺留代碼。持續集成：確保新的提交已通過測試
有沒有辦法，我就可以建立，整合服務器檢查所有新提交過測試（比如，覆蓋率> 70％）的最小量什麼辦法？
從本質上講，我看到兩個選項：
我更喜歡選項1，因爲它強制更改遺留代碼以進行單元測試。這應該會增加整體測試覆蓋率。
現在我們使用Jenkins作爲CI服務器，JaCoCo使用測試覆蓋率。 Maven用於構建項目，SVN是我們的主要源代碼控制。
我知道你可以配置詹金斯驗證至少有一個測試文件中的承諾的一部分。這不能確保良好的測試覆蓋率，但至少你會知道有某種測試相關的變化。
我不喜歡這個想法。如果您正在提交一些信息來做出先前失敗的測試通過，則不需要同時提交測試文件。 – JohnnyO 2013-04-03 18:54:30
@JohnnyO理論上講，一個失敗的構建**不應該首先被提交。除非你的單元測試是片面的或與外部依賴關係相關，這是一組不同的問題，否則你不應該承諾修復破損的單元測試。 – 2013-04-03 19:33:31
理論上肯定。在實踐中，不是那麼多。想象一下你有一個不好的提交（假設你忘記包含一個文件）。所以，測試通過本地，但在詹金斯失敗。在這種情況下你會如何提交丟失的文件？ – JohnnyO 2013-04-04 12:44:11
對於選項2，可以使用Jenkins JaCoCo plugin來跟蹤每個構建的代碼覆蓋率，並根據覆蓋率度量標準將構建結果設置爲通過或失敗。
我喜歡選項1更好，太多，但我不知道詹金斯做這個內置的方式。它應該是相當容易（至少在類級別）進行後處理的覆蓋數據，並與SVN版本信息結合起來，是這樣的：
這不是一個完整的解決方案，對於未包含在測試中的新方法或新行來說，它會變得更復雜。給我一個新的Jenkins插件的想法;-)
但我如何配置這個插件失敗，如果提交的更改沒有覆蓋測試？如果我在傳統文件中添加一個小的更改，這可能不會更改整體覆蓋率度量，因此不會使構建失敗？ – 2013-04-03 18:59:37
對，這就是爲什麼我包含了我對你的第一個選項的評論。 – 2013-04-03 19:01:00
我會焦急地等待你的插件。 – 2013-04-03 19:01:53
一些覆蓋工具（如cobertura）支持排除軟件包。這樣，您可以排除所有舊代碼（假設它可以進行模式匹配）並讓cobertura僅檢查新代碼（其中包含新提交）。
我希望這會有所幫助。
感謝您的意見，但我的目標是確保新代碼經過測試，並強制更改舊代碼以進行測試。 – 2013-04-03 18:56:30
我建立了一個工具，它正是這樣做的
https://github.com/exussum12/coverageChecker
您通過分支的diff和從測試輸出遮蓋試驗。該工具確定diff中哪些行也在三葉草文件中。和失敗構建如果低於一定比例
使用
bin/diffFilter --phpunit diff.txt clover.xml 70
失敗構建時，DIFF小於70％由測試覆蓋
我可以添加其他格式，如果需要
編輯
我已經加入jacoco
Bin/diffFilter --jacoco diff.txt jacoco.xml
請記住，100％的覆蓋率不一定是可能的，甚至不需要。覆蓋範圍數字也可以被操縱。爲測試類寫單元測試可能會人爲地誇大測試覆蓋率。 – 2013-04-03 18:51:06
@MikeRylander我知道，我甚至不夢想在這個項目上100％的覆蓋率。但我仍然認爲，迫使新的變化至少有一些報道是好的。 – 2013-04-03 18:54:41
我目前正在解決這個問題，主要解決@MikeRylanders的評論。現在http://pitest.org與版本控制集成在一起。下一個版本將允許通過scm狀態分析文件。以下版本將允許按日期範圍或提交進行分析，這將允許構建服務器檢查修改的代碼是否滿足給定的變異分數。 – henry 2013-04-19 16:13:30