2017-05-30 82 views
4

我在Ubuntu 14.04 LTS上使用摩卡(版本2.4.5_6)和流星版本1.4.4.1的流星覆蓋包(版本1.1.4)。我已經能夠生成非常漂亮的測試覆蓋率報告,但是對於客戶端測試來說似乎有些不妥。爲了覆蓋數據發送到本地主機:3000 /報道我已經創建了一個函數調用sendCoverage(),我在我的.tests.js導入文件:流星覆蓋似乎顯示未執行的語句

export const sendCoverage = function sendCoverage() { 
    Meteor.sendCoverage(function(stats,err) {console.log(stats,err);}); 
}; 

我調用這個函數的摩卡測試塊後:

after (function() { 
    sendCoverage(); 
}); 

現在,這將產生在我的本地測試覆蓋報告:3000 /覆蓋頁,但它好像不正確顯示的覆蓋範圍。例如,我看到一些語句被執行,但以紅色突出顯示,並且標記爲未覆蓋。例如:

coverage example

它好像在語句被分別執行11個12倍。但是,他們沒有被標記爲被覆蓋,在我的報告中,報告覆蓋率的百分比反映了這一點。

有沒有人知道我可能做錯了什麼和/或有客戶端代碼覆蓋率和流星覆蓋包的經驗?

謝謝!

後的解決方案編輯

看來我知道了現在的工作。 Codacy上的百分比與我的html報告中的百分比相符。更仔細地看待html報告,看起來覆蓋率數字畢竟是正確的。這只不過是顯示出奇怪行爲的向下鑽取。因此,結論是它畢竟奏效了,但是Codacy的第二個意見向我證實了這一點。我的新方法是使用spacejam創建lcov覆蓋率報告(請參閱Ser的答案),並將它們導出到外部服務,如Codacy,Codecov或SonarQube。

感謝Serut的輸入!

回答

1

我是流星覆蓋的作者。很高興看到該軟件包在您的應用中運行良好!

首先,我不認爲你的收集覆蓋範圍和保存報告的方式是優化的:不要創建具有保存覆蓋範圍的函數的utils。您只需使用(假設Meteor.sendCoverage始終存在於測試中)即可保存每個文件的覆蓋範圍。

after (function() { 
    Meteor.sendCoverage(()=>{}); 
}); 

另一方面,您不應該在測試文件中編寫任何代碼以保存覆蓋率。測試運動員可以爲你做什麼,比如I added on the spacejam fork。您可以嘗試使用serut/spacejam導出htmllcov報告。

我認爲lcov格式比html報告更可靠。如果我看一下coverage report of the client side code from meteor-coverage,一切看起來都很連貫。嘗試將lcov文件發送到Sonar,Codecov或Codacy等Code Quality平臺。我希望它能解決線問題,這可能與伊斯坦布爾及其html報告生成有關。

+0

嘿塞魯特,謝謝你的回答!我試圖使用spacejam以你解釋的方式運行測試。但是,這導致在我的控制檯中輸出以下錯誤: '=>啓動代理。 =>啓動MongoDB。 spacejam:流星mongodb已準備就緒 spacejam:殺死流星 spacejam:未知錯誤,退出代碼爲null。退出.' 我試圖找到關於此在線的任何內容,但與此相關的所有問題似乎都與Windows支持有關,因爲我在Ubuntu上開發我的應用程序似乎並不適用於我。你知道這個錯誤可能來自哪裏嗎? – Gijs

+0

stacktrace太短,不能讓我知道發生了什麼,它可能是你啓動'spacejam'的方式(使用'meteor npm run ')或者與你的設置有關的錯誤。檢查[我用apollographql/meteor-starter-kit製作的這個fork](https://github.com/serut/meteor-react-apollo-test-coverage-starter-kit)查看我對增加覆蓋面。或者[填寫問題](https://github.com/serut/meteor-coverage/issues),如果你想修復這個問題。 – Ser

+0

好的,所以我設法讓spacejam運行起來。畢竟,我確實必須使用https:// github.com/serut/spacejam/tarball/windows-suppport-rc4'版本。能夠在您的倉庫中使用提供的package.json命令創建lcov文件,並能夠將其發送到Codacy進行分析。不幸的是,百分比仍然是相同的,這意味着線路仍然必須被錯誤計數。儘管如此,我還有一步,所以迄今爲止感謝你!我會繼續嘗試找出錯誤並保持這個線程更新。如果您在此期間還有其他建議,請告訴我! – Gijs