2011-07-29 44 views
4

我在想,如果你們中的任何一個人在運行NUnit測試時在TFS構建服務器2010中生成代碼覆蓋率報告的經驗。TFS使用NUnit構建2010代碼覆蓋範圍

我知道使用打包替代方法(MSTest +啓用testrunco​​nfig文件覆蓋範圍)可以輕鬆完成此操作,但使用NUnit時會涉及更多一點。我在這裏和那裏發現了一些信息,指向NCover,但似乎過時了。我想知道是否還有其他選擇,以及是否有人實際執行了這個。

下面是關於我們的環境/需要更多的信息: - TFS構建服務器2010 - 測試都是純類庫(未測試庫 - 即沒有關聯的testrunco​​nfig文件),並在NUnit的實現。我們沒有MSTests。 - 我們有興趣將覆蓋範圍報告作爲每個構建的一部分運行,並且如果可能的話,設置合格/不合格標準的覆蓋閾值要求。

回答

4

我們用NUnit-NCover完成了它,並對我們的結果非常滿意。
NUnit執行之後是NUnitTfs執行,以便讓我們的測試結果在生成日誌中發佈。然後NCover開始,生成我們的代碼覆蓋率結果。

作爲一個缺點的一個主要問題是,設置正確調用NCover的參數並不是微不足道的。但是自從我安裝它之後,我從來不需要維護它。

兩件事情可能會帶來的缺點:

  • NUnitTfs不NCover(很好地工作,至少我無法找到一個方法來執行這兩個在同一步驟,所以(因爲NCover NUnit的調用)我必須進行兩次單元測試:(1)獲得測試結果,(2)獲得NCover的覆蓋結果。當然,這使得我的構建持續更長時間。
  • 設置正確調用NCover的參數wasn' t瑣碎,但自從我安裝它,我從來沒有維護它。

在任何情況下,生成的報告(特別是趨勢方面)在監視我們的代碼如何在時間內演變時非常有用。特別是如果您正在開發一個平臺(而不是短期項目),趨勢報告具有很大的價值。

編輯
我會盡力呈現一個快速&骯髒的方式我如何'已經實現了這個,我希望它是有用的。我們目前在我們的構建服務器上擁有NCover 3.4.12。
關於我們的NUnit程序集的簡單命名約定是,如果我們有一個生產程序集「123.dll」,則存在另一個名爲「123_nunit.dll」的程序集來實現它的測試。所以,每個版本都有幾個感興趣的* _nunit.dll程序集。

「如果不禁用測試」下的構建過程模板中的部分是爲了實現我們的目標而重新構建的部分,特別是名爲「爲測試程序集運行MSTest」的部分。整個實現是here,經過一些清理,使流程更容易理解(圖片太大,無法直接插入此處)。

起初,一些額外的參數在構建過程中模板&實現然後可在每個構建定義設置:
enter image description here

然後,我們形成「制定nunitCommandLine」 NUnit的ARGS:

String.Format("{0} /xml={1}\\{2}.xml", nunitDLL, TestResultsDirectory, Path.GetFileNameWithoutExtension(nunitDLL)) 

這然後在 「調用NUnit的」
enter image description here

我用這種情況成功&我們已經爲這個構建設置了覆蓋範圍,我們轉到「生成NCover NCCOV」(這個特定程序集的覆蓋文件)。爲此,我們調用NCover.Console.exe具有以下的參數數量:

String.Format("""{0}"" ""{1}"" //w ""{2}"" //x ""{3}\{4}"" //literal //ias {5} //onlywithsource //p ""{6}""", 
       NUnitPath, 
       Path.GetFileName(nunitDLL), 
       Path.GetDirectoryName(nunitDLL), 
       Path.GetDirectoryName(Path.GetDirectoryName(nunitDLL)), 
       Path.GetFileName(nunitDLL).Replace("_nunit.dll", ".nccov"), 
       Path.GetFileNameWithoutExtension(nunitDLL).Replace("_nunit", ""), 
       BuildDetail.BuildNumber) 

所有這些運行在foreach循環中「對於所有的NUnit的dll」。當我們退出循環,我們在第一部分「合併NCCovs」,其中NCover.Console.exe再次執行進入「最終NCover活動」 & - 這一次不同ARGS:

String.Format("""{0}\*.nccov"" //s ""{0}\{1}.nccov"" //at ""{2}\{3}\{3}.trend"" //p {1} ", 
       Path.GetDirectoryName(Path.GetDirectoryName(testAssemblies(0))), 
       BuildDetail.BuildNumber, 
       NCoverDropLocation, 
       BuildDetail.BuildDefinition.TeamProject 
      ) 

當這個已經運行,我們已經達到了將這個版本的所有NCCOV文件合併到一個NCCOV文件中,這個文件是在構建之後命名的。趨勢文件(在整個生命週期中監視構建)已經用當前版本的元素進行了更新。

我們現在只生成最終的HTML報告,這是在「生成最終NCover代表」在這裏我們調用NCover.reporting具有以下ARGS完成:

String.Format(" ""{0}\{1}.nccov"" //or FullCoverageReport //op ""{2}\{1}_NCoverReport.html"" //p ""{1}"" //at ""{3}\{4}\{4}_{5}.trend"" ", 
       Path.GetDirectoryName(Path.GetDirectoryName(testAssemblies(0))), 
       BuildDetail.BuildNumber, 
       PathForNCoverResults, 
       NCoverDropLocation, 
       BuildDetail.BuildDefinition.TeamProject, 
       BuildType 
      ) 
+0

謝謝!我們很快就會嘗試。有兩次運行測試似乎有點痛苦,但我願意爲報告目的付出代價。我敢肯定,如果需要,我們可以設法讓它們並行運行。幾個後續問題:(1)你有任何資源來設置這個你可以分享? (2)您是否有針對您的覆蓋率數據設置的構建失敗/傳遞標準(例如,當覆蓋率<80%時,使構建失敗)? – rtorres

+0

你好rtorres,很高興成爲服務!我目前正在度假,所以我對我的資源的訪問有限 - 在幾周內幫助不成問題。關於(2):不,我不這樣做,因爲我策略性地將代碼覆蓋率視爲我們代碼質量的「軟」指標 - 但我相信如果您需要它,可以完成此操作。 – pantelif

+0

太好了,謝謝你的幫助。在#2,是的,我同意,覆蓋面不是一個直接的質量指標。我們希望將這些閾值設置爲幫助我們改進開發團隊測試習慣的一種方式(我們從0%開始,所以希望避免滑倒)。 – rtorres