Code coverage tools for Elixir?

No, as InstanbulJS is ECMAScript specific. There is no “general purpose” coverage analysis tool, as this kind of metric is highly language/platform dependant.

You can check out cover module to see what you can get out of it. As far as I know this is only coverage tool available.

I already did it. This module is what I refer to as the native cover tool and all the drawbacks I present are actually drawbacks of cover - which is why I was trying to find an alternative.

So sad this is the only choice we have …

Have you tried https://github.com/parroty/excoveralls?

…

The point is that in Erlang there is no much difference between statements and lines, so I would roughly say that line = statement. Second stat is branch which also do not make much sense, as most of the time Erlang will use pattern match, so it will be split into 2 categories:

• function clauses
• lines

Both of these are available in cover module.

Functions are available as well as modules in cover, so that shouldn’t be much of the issue either.

So as you can see that metrics either do not make sense or are supported in Erlang’s cover.

No. Lines are not statements.

Second stat is branch which also do not make much sense, as most of the time Erlang will use pattern match,

No, branches !== pattern matching. A single if can have several branches. This has nothing to do with pattern matching nor multi-clause functions.

The fact that in Elixir you can have multiclause functions thanks to pattern matching and avoid long if or cond statements is a nice feature, but pattern matching together with guards can only take you so far and even though all multiclause functions can be converted to if counterparts, the reverse is not possible.

I recommend you dive deeper into the world of coverage metrics. Only then will you understand that they do make sense.

Erlang do not have notation of “statement” in its’ .beam files, only lines are stored. While in theory you could use 'Abst' chunk to extract “statements” it would be infeasible due to macros (especially in Elixir), and even then there is no mapping between 'Abst' values and 'Code' segments (only 'Line' have such relation).

So unless you write EEP to introduce such connection between “statement” and 'Code' chunk then it is not possible with current VM implementation.

Yes, usually (and in Elixir always) 2.

It is possible, but not always feasible.

Any code in form of:

if a, do: b, else: c

can be written as:

def do_branch(true), do: b
def do_branch(false), do: c

do_branch(a)

And it doesn’t matter what is a.

This is interesting. It appears that even though no .beam file is created, you are still correct !

I would agree with you if only guards weren’t limited. The limitations with guards directly imply that some conditions cannot be converted into the pattern matching formula. For example, Map.key? can’t be used in a guard. if you have

if Map.key?(a), do: b, else: c

Then you are stuck.

Interesting discussion overall, can’t wait to see where it leads!

Conclusions so far:

1. Differentiating between lines and statements makes no sense in Erlang/Elixir because BEAM doesn’t have the concept of statements. For BEAM, every line is a statement.

FWIW the current cover tool does not use the assembly stored in .beam files. What it does is to retrieve the Erlang AST for the module, transform it and recompile.

The transformation consists primarily of introducing calls to :ets.update_counter/3 each time the line annotation of the AST changes. The analysis is just counting how many lines could be called vs how many were actually called.

An Elixir version that worked on Elixir AST in a similar way wouldn’t be extremely hard to do. It could also inject the counter calls for each branch, etc, to achieve the desired coverage.

No exactly, the difference is that JS is interpreted, so it has no notion of “compiled code”. In Erlang on the other hand there is such possibility, and single line can result in multiple VM “statements”, for example:

Integer.to_string(a + 1)

Will result with 2 instructions:

    {line,[{location,"lib/tasks.ex",6}]}.
    {gc_bif,'+',{f,0},1,[{x,0},{integer,1}],{x,0}}.
    {line,[{location,"lib/tasks.ex",6}]}.
    {call_ext_only,1,{extfunc,erlang,integer_to_binary,1}}.

So you can see that it is hard to match statements to instructions, especially as in theory compiler is free to reorder commands as it pleases as long as the result is the same (this can be especially seen in C/C++ where it is written in standard, and result of it is that foo(a++, a++) is undefined behaviour).