Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uncovered lines, but no red lines in HTML file #25

Open
KronicDeth opened this issue Feb 24, 2016 · 12 comments
Open

Uncovered lines, but no red lines in HTML file #25

KronicDeth opened this issue Feb 24, 2016 · 12 comments

Comments

@KronicDeth
Copy link

I have multiple modules where Module Coverage Report says there are uncovered lines, but the Coverage Source code shows no red. Where are the missing lines? Is there some way to see how the count is being generated so I can find the missing lines outside of the Coverage Source code html?

@alfert
Copy link
Owner

alfert commented Feb 27, 2016

This could be a duplicate of #24. All coverage information comes from the Erlang coverage utility. The job of coverex is to generate nicely formatted reports. I use the analysis-functions from :cover(see http://erlang.org/documentation/doc-7.2/lib/tools-2.8.2/doc/html/cover.html). However strange things sometimes happens: One liner functions do not appear in the source code as red or green marked, but are completely covered in the function list.

Do you have an example for your case, so I can take a look at?

@scouten
Copy link
Contributor

scouten commented Aug 18, 2016

If this is still an issue, I have a very small codebase which is demonstrating this. LMK and I can send it to you.

(FWIW, I am also seeing red lines where they probably shouldn't be.)

@alfert
Copy link
Owner

alfert commented Aug 22, 2016

Yes, I am interested to understand whether it's an issue with cover or with coverex.

@scouten
Copy link
Contributor

scouten commented Aug 22, 2016

Here you go, about as minimal as it gets. 😄

coverex-bug-demo.zip

@scouten
Copy link
Contributor

scouten commented Aug 22, 2016

Specifically, the coverage for Elixir.Thing reports a missed line for defstruct as shown:

screen shot 2016-08-22 at 15 04 48

@alfert
Copy link
Owner

alfert commented Aug 23, 2016

Ouch. I get also very interesting numbers on the console for that file: 42% coverage is not the intuitively expected value of 75% :-/

My initial guess is that macro construct of of defstruct generating a lot of AST elements for that single line confuses the numbers I get from :cover. I need to meditate about this issue. Ideas what a desirable result should be like are very welcome.

@scouten
Copy link
Contributor

scouten commented Aug 24, 2016

IMHO (and understand that I'm very new to Elixir) defstruct isn't really executable, so should be neither hit nor missed.

@Eiji7
Copy link

Eiji7 commented Dec 10, 2016

@alfert: I don't know if I understand this correctly, but for me (I'm new in Elixir too) it looks like (in this example) that macro calls are never covered if there are not in functions that was called in tests. How about to write test to force recompile all project files? If I good understand after compile all macro outside methods will be called to prepare modules, so they would be covered, right?

@fcevado
Copy link

fcevado commented Apr 23, 2017

@Eiji7 if that's the case, the flag --force should resolve it.

@tiagoefmoraes
Copy link

I have found that inspecting the struct covers defstruct, don't know why.

%Thing{} |> inspect()

image image

@alfert
Copy link
Owner

alfert commented Jan 15, 2022

The defstruct issue is interesting, but it follows the above thread: defstruct is a macro, executed during compile time. It creates a bunch byte code which is attached to the line defining the defstruct. In contrast to %Thing{}, which is expanded by the compile (think: inlining), for inspect() we need to implement the Inspect protocol. From the behaviour of :cover we can conclude that the default implementation is attached to the defstruct code generation.

tiagoefmoraes added a commit to tiagoefmoraes/coverex-bug-demo that referenced this issue Apr 7, 2022
@tiagoefmoraes
Copy link

In SpryCov I started not reporting defstruct lines by getting __struct__ functions line number from docs and ignoring those lines.

If you want to try it out I created a repo with scouten's sample here https://github.com/tiagoefmoraes/coverex-bug-demo/branches, just checkout a branch and run mix deps.get && mix test --cover

This is the report before and after this change.

Before After
Screenshot from 2022-04-07 18-26-18 Screenshot from 2022-04-07 18-43-38

And here is the commit that does that
tiagoefmoraes/spry_cov@7efbc80#diff-06c01cd05f14b94ad5adf87670e5335ac6a128f3d1fcaa23b9ef8187d791cdb0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants