Open KronicDeth opened 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?
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.)
Yes, I am interested to understand whether it's an issue with cover
or with coverex
.
Here you go, about as minimal as it gets. 😄
Specifically, the coverage for Elixir.Thing reports a missed line for defstruct
as shown:
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.
IMHO (and understand that I'm very new to Elixir) defstruct
isn't really executable, so should be neither hit nor missed.
@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 if that's the case, the flag --force
should resolve it.
I have found that inspecting the struct covers defstruct
, don't know why.
%Thing{} |> inspect()
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.
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 |
---|---|
And here is the commit that does that https://github.com/tiagoefmoraes/spry_cov/commit/7efbc80fe1f54f86a557a03e17a48adfcfc980fc#diff-06c01cd05f14b94ad5adf87670e5335ac6a128f3d1fcaa23b9ef8187d791cdb0
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?