Skip to content
This repository has been archived by the owner on Jan 27, 2021. It is now read-only.

Display code coverage report on console on dotnet test --collect "Code Coverage" #8

Open
smadala opened this issue Jul 23, 2018 · 8 comments
Assignees
Labels
blocker enhancement New feature or request

Comments

@smadala
Copy link
Contributor

smadala commented Jul 23, 2018

Description

  • dotnet test --collect "Code coverage" should show coverage info for each module on console

Steps to reproduce

Expected behavior

Something similar to below image
code-coverage-cli-report

Actual behavior

  • dotnet test just prints .coverage file path.
Test run for C:\Users\samadala\tmp\cc-mstest\bin\Debug\netcoreapp2.0\cc-mstest.dll(.NETCoreApp,Version=v2.0)
Microsoft (R) Test Execution Command Line Tool Version 15.8.0-preview-20180605-02
Copyright (c) Microsoft Corporation.  All rights reserved.

Starting test execution, please wait...

Attachments:
 C:\Users\samadala\tmp\cc-mstest\TestResults\ab987d22-bcc9-4748-a04d-071bbe9851c3\samadala_SAMADALA_2018-07-23.18_54_39.coverage

Total tests: 1. Passed: 1. Failed: 0. Skipped: 0.
Test Run Successful.
@codito
Copy link
Contributor

codito commented Jul 24, 2018

There are two implementation approaches:

  • Author msbuild tasks for converting .coverage to .lcov
  • Author a vstest logger to convert the .coverage to .lcov

What are the pros and cons? Why is former better than later?

IMHO, second approach would have helped us in the Translation Layer case as well. Imagine someone triggering test run directly on file save (instead of running dotnet watch to do it). We could actually enable a continuous coverage tool.

@smadala
Copy link
Contributor Author

smadala commented Jul 24, 2018

CoverageLogger looks something similar to https://github.com/smadala/samples/tree/master/CoverageLogger

/cc @mayankbansal018

@harshjain2
Copy link
Contributor

harshjain2 commented Jul 24, 2018

If I have to break down the overall process for converting .coverage to .lcov, these are the steps involved:

  1. Convert .coverage to .xml file.
  2. [Optional, can be controlled through switch] Read the .xml to read the coverage percentage.
  3. Convert .xml file to .locv.

IMHO, we should create vstest logger for achieving 1 and 2.
3 may or may not be part of the same logger.

@codito
Copy link
Contributor

codito commented Jul 24, 2018

Awesome. Is someone already working on getting the coveragelogger into this repo?

Logger should also involve displaying the information in .lcov.

Please keep everything lcov related in a separate library. Or is there an already existing one we could reuse? I can imagine too many use cases for it ;). E.g. we can later reuse this component to display coverage output for opencover or anyother coverage engine. It can be used for parsing and populating vscode editor too.

@smadala
Copy link
Contributor Author

smadala commented Jul 25, 2018

Is someone already working on getting the coveragelogger into this repo?

@harshjain2 Has worked on this yesterday. Today I'm planning to work with him and you. To get this to closer.

Please keep everything lcov related in a separate library. Or is there an already existing one we could reuse?

For POC, I'm not much worried on architecture/reusable . If we have proper tests(TDD) we can refactor it later 😄

@codito
Copy link
Contributor

codito commented Jul 25, 2018

I don't have the required OS to work on this issue.

For POC, I'm not much worried on architecture/reusable . If we have proper tests(TDD) we can refactor it later

Your call :)

@smadala
Copy link
Contributor Author

smadala commented Jul 25, 2018

I don't have the required OS to work on this issue.

Any time today, drop by my desk, We can do pair programming on my machine 😄

Your call :)

Scoping down everything. We have DEADlines 😄

@codito
Copy link
Contributor

codito commented Jul 26, 2018

Picking up #27 to complete this.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
blocker enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants