# Code Coverage Metrics **URL:** \ **Category:** Released\ **Tags:** released\ **Created:** [February 9, 2017, 1:15pm UTC](https://discuss.bitrise.io/t/code-coverage-metrics/707 "2017-02-09T13:15:13Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![viktorbenei](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/viktorbenei/32/18_2.png) [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)\ **Post date:** [February 9, 2017, 1:15pm UTC](https://discuss.bitrise.io/t/code-coverage-metrics/707/1 "2017-02-09T13:15:13Z")
_From Anonymous on 2015/05/30 11:25:36 +0000_ It’s very useful for developers to see test coverage for a project and its classes. It’s very important for Product Owners and Project Managers to have access to this information without developer assistance so they can plan next stages of work, concentrate on deficient code or have an early warning system to begin asking questions or begin planning accordingly if test coverage starts to drop. Other competing services such as Travis and Circle both implement support for Coveralls (and get Slather as a knock on benefit). I propose Bitrise either builds in Coveralls and Slather support or rolls a Bitrise specific solution which takes advantage of the test coverage files delivered after an Xcode build. _Copied from original feature request: [http://bitrise.uservoice.com/forums/235233-general/suggestions/8168802-code-coverage-metrics](http://bitrise.uservoice.com/forums/235233-general/suggestions/8168802-code-coverage-metrics)_ ---
**Author:** ![viktorbenei](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/viktorbenei/32/18_2.png) [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)\ **Post date:** [February 9, 2017, 1:15pm UTC](https://discuss.bitrise.io/t/code-coverage-metrics/707/2 "2017-02-09T13:15:14Z")
_From Vinayak Badrinathan on 2016/06/03 19:18:14 +0000_ In case anyone else is looking for another way, here's what I did: I enabled 'gather coverage data' under my test section in my scheme. I then added a lane in fastlane that does the following: - runs unit tests with the scheme mentioned above - invokes slather via the command line and captured stdout, stderr, and status via the gem Open3 - added a regex that looks for the final test coverage results from slather's stdout output - if it's non-nil, the coverage number was parsed and we can write some logic to check that against the project's limit Surely, the code in the gist can be cleaner, but it'll give you an idea of how you can add code coverage and a minimum threshold. Example code: [https://gist.github.com/vinnybad/efe32d7594ac7c1fe07bacffdb68b4ed](https://gist.github.com/vinnybad/efe32d7594ac7c1fe07bacffdb68b4ed) ---
**Author:** ![viktorbenei](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/viktorbenei/32/18_2.png) [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)\ **Post date:** [February 9, 2017, 1:15pm UTC](https://discuss.bitrise.io/t/code-coverage-metrics/707/3 "2017-02-09T13:15:15Z")
_From Kyle McAlpine on 2016/01/12 14:34:48 +0000_ I've written a bit about this on the Bitrise contrib repo here: [https://github.com/bitrise-io/bitrise-contrib/issues/3](https://github.com/bitrise-io/bitrise-contrib/issues/3) It seems that Slather is not really being maintained anymore. Last commit was in October. So we're working on a replacement: > **[GitHub - kylejm/Parasol: ⛱ Reformats Coverage.profdata file that Xcode 7...](https://github.com/kylejm/Parasol)** > > ⛱ Reformats Coverage.profdata file that Xcode 7 generates for use by humans and CIs - GitHub - kylejm/Parasol: ⛱ Reformats Coverage.profdata file that Xcode 7 generates for use by humans and CIs Goal is to output: - JSON - Cobertura - HTML from the new Xcode Coverage.profdata code coverage file. Contributors very much welcome 🙂 ---
**Author:** ![viktorbenei](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/viktorbenei/32/18_2.png) [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)\ **Post date:** [February 9, 2017, 1:15pm UTC](https://discuss.bitrise.io/t/code-coverage-metrics/707/4 "2017-02-09T13:15:16Z")
_From Bitrise on 2015/10/30 14:22:31 +0000_ For this you now can use the Codecov step ([https://github.com/bitrise-io/steps-codecov](https://github.com/bitrise-io/steps-codecov)) which will generate and upload a code coverage report to Codecov ([https://codecov.io](https://codecov.io)). We haven't closed this idea, as we are curious what other related features you'd need. ---
**Author:** ![viktorbenei](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/viktorbenei/32/18_2.png) [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)\ **Post date:** [February 9, 2017, 1:19pm UTC](https://discuss.bitrise.io/t/code-coverage-metrics/707/5 "2017-02-09T13:19:03Z")
Most of these things are possible now, the only thing which prevents you from easily checking the code coverage metrics of a build is: > [@Artifacts: Make it possible to view HTML files with relative links (CSS etc. refs)](http://discuss.bitrise.io/t/artifacts-make-it-possible-to-view-html-files-with-relative-links-css-etc-refs/145): > > From @viktorbenei on Sat Dec 10 2016 10:29:41 GMT-0500 (EST) Right now artifacts are exposed with special, pre-signed, time limited URLs. This means that the exact download / access link for an artifact is generated and does change every time it’s accessed. This makes relative links between artifacts unusable when viewed directly on the web UI. This issue mainly affects HTML files/reports, where the HTML file references other resources (like CSS, JavaScript, etc. files) with relative links. F… ---
**Author:** ![bitce](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/bitce/32/1639_2.png) [@bitce](https://discuss.bitrise.io/u/bitce)\ **Post date:** [August 31, 2021, 9:43am UTC](https://discuss.bitrise.io/t/code-coverage-metrics/707/6 "2021-08-31T09:43:46Z")
Closed on August 31, 2021, 9:43am UTC