coverex icon indicating copy to clipboard operation
coverex copied to clipboard

Uncovered lines, but no red lines in HTML file

Open KronicDeth opened this issue 8 years ago • 12 comments

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?

KronicDeth avatar Feb 24 '16 16:02 KronicDeth

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?

alfert avatar Feb 27 '16 11:02 alfert

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.)

scouten avatar Aug 18 '16 00:08 scouten

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

alfert avatar Aug 22 '16 19:08 alfert

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

coverex-bug-demo.zip

scouten avatar Aug 22 '16 22:08 scouten

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

screen shot 2016-08-22 at 15 04 48

scouten avatar Aug 22 '16 22:08 scouten

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.

alfert avatar Aug 23 '16 21:08 alfert

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

scouten avatar Aug 24 '16 00:08 scouten

@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?

Eiji7 avatar Dec 10 '16 11:12 Eiji7

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

fcevado avatar Apr 23 '17 20:04 fcevado

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

%Thing{} |> inspect()

image image

tiagoefmoraes avatar Jan 13 '22 00:01 tiagoefmoraes

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.

alfert avatar Jan 15 '22 13:01 alfert

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

tiagoefmoraes avatar Apr 07 '22 22:04 tiagoefmoraes