Giter Club home page Giter Club logo

Comments (10)

jbblanchet avatar jbblanchet commented on August 20, 2024 6

Hi!

I think we need something similar, but let me know if this is a separate issue and I'll gladly create it.

Let's say we have 3 separate packages A, B and C, and we want to have the total coverage stats. All packages are independent.

If we only have tests for B and C, the output of gocov test A B C | gocov report will be something like:

?       A       [no test files]
ok      B       0.001s   coverage: 50.0% of statements
ok      C       0.001s   coverage: 100.0% of statements

B   functionX   100.00% (12/12)
B   functionY     0.00% (0/12)
B   ----------   50.00% (12/24)

C   functionZ   100.00% (12/12)
C   ----------  100.00% (12/12)

Total Coverage: 66.67% (24/36)

What we'd like is to see:

?       A       [no test files]
ok      B       0.001s   coverage: 50.0% of statements
ok      C       0.001s   coverage: 100.0% of statements

A   functionF     0.00% (0/12)
A   ----------    0.00% (0/12)

B   functionX   100.00% (12/12)
B   functionY     0.00% (0/12)
B   ----------   50.00% (12/24)

C   functionZ   100.00% (12/12)
C   ----------  100.00% (12/12)

Total Coverage: 50.00% (24/48)

Does that make sense?

from gocov.

nat-brown avatar nat-brown commented on August 20, 2024 3

This is a very old issue, but I would like to add that I resolved this for my project with
gocov test $(go list ./... | grep -v -E '/vendor/') -coverpkg=$(go list ./... | grep -v -E '/vendor/' | tr '\n' ',') | gocov-xml > cobertura.xml
This uses the xml output from the other project, but I suspect it would work for this project's report functionality as well. Note that the output is cluttered during the test running phase, but the generated xml file is correct.

from gocov.

axw avatar axw commented on August 20, 2024 1

@axw Thanks for the quick response!

It helps that we're in the same timezone :)

sorry, I think transitively imported packages doesn't 100% satisfy me. lol. I would like something that "recursively" reports the total lines in all packages (except the ignored ones).

I think we mean the same thing. I mean that if A imports B, and B imports C, then running "gocov test A" will show the coverage for A, B, and C.

And I'm very much willing to contribute! Perhaps not today though, maybe in this weekend?

Great. No rush on my side, so whenever you are able. I'll be happy to review and provide pointers as necessary.

from gocov.

axw avatar axw commented on August 20, 2024

Ideally, when I run gocov test ./... under a certain project folder, I want to see the reported total line numbers be the total lines to be covered in the project, no matter whether there is test file existing for a certain package or not.

The way "gocov test ./..." is currently handled is a bit dumb/naive: it runs "go test -coverprofile=..." for each package that "./..." matches, independently, and them accumulates the results. Each independent coverage profile includes the data for only that package, because -coverpkg isn't passed to the go test command.

What I think we should do is include the coverage data for (transitively) imported packages too. So if you have

  • package ./A, with tests
  • package ./B, without tests
  • package ./A imports package ./B

then gocov test ./... should run the tests in package A, and that should include the coverage data for both A and the imported package B.

This would be achieved by passing -coverpkg <imported-packages> to each go test command execution. Adding a flag to exclude packages sounds fine to me; that would just have the effect of removing that package from the list passed to -coverpkg.

Would that satisfy you?

(This is what I wanted all along, but I never had the time/inclination to do it myself. I may bite the bullet and do it now, but if you feel up to contributing, I'd be happy for the help.)

P.S. gocov is really an awesome and handy tool! It enables and empowers me to do my testing job! :)

I'm very glad to hear that; thank you for saying so.

from gocov.

chao1995 avatar chao1995 commented on August 20, 2024

@axw Thanks for the quick response!

What I think we should do is include the coverage data for (transitively) imported packages too.

sorry, I think transitively imported packages doesn't 100% satisfy me. lol. I would like something that recursively reports the total lines in all packages (except the ignored ones).

(edit: "recursive" might not be the correct word to use. actually my idea is to line-count every go files except the ignored ones. even for those that are not imported or used in any ways.)

And I'm very much willing to contribute! Perhaps not today though, maybe in this weekend?

from gocov.

axw avatar axw commented on August 20, 2024

@jbblanchet yup, makes sense - that would be solved with the proposed change

from gocov.

BryanLipscy42 avatar BryanLipscy42 commented on August 20, 2024

@axw Can you pretty please merge this fix?

from gocov.

axw avatar axw commented on August 20, 2024

@BryanLipscy42 this is just an issue, so there's nothing to merge. If you or anyone else would like to propose changes, please go ahead and I would be happy to review them.

from gocov.

BryanLipscy42 avatar BryanLipscy42 commented on August 20, 2024

@axw Thank you

from gocov.

axw avatar axw commented on August 20, 2024

Having said that, the goal can now be achieved through the use of appropriate flags. IIRC, a long time ago it was not possible to run go test -cover ./..., so gocov had some code to work around that. At some point it became possible to run go test -cover with patterns.

Try this (substituting for the -coverpkg patterns): gocov test -coverpkg=a,b,c ./...

This has the same meaning as when running go test -cover directly:

  • Run the tests for all packages in ./...
  • Include the coverage for packages "a", "b", and "c"

I just tested this and confirmed it works, so I'm going to close this issue. Let me know if I missed something.

from gocov.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.