alfert / coverex

Coverage Reports for Elixir
Other
101 stars 26 forks source link

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

Open KronicDeth opened 8 years ago

KronicDeth commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

scouten commented 8 years ago

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

coverex-bug-demo.zip

scouten commented 8 years ago

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

screen shot 2016-08-22 at 15 04 48
alfert commented 8 years ago

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 commented 8 years ago

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

Eiji7 commented 7 years ago

@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 commented 7 years ago

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

tiagoefmoraes commented 2 years ago

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

%Thing{} |> inspect()

image image

alfert commented 2 years ago

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 commented 2 years ago

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 https://github.com/tiagoefmoraes/spry_cov/commit/7efbc80fe1f54f86a557a03e17a48adfcfc980fc#diff-06c01cd05f14b94ad5adf87670e5335ac6a128f3d1fcaa23b9ef8187d791cdb0