HEEX template files not included in code coverage

ChristianAlexander

Hi there!

Is there a way to include heex files in code coverage reporting? It appears that ~H sections within .ex files such as views and components are reported, but when the templates are in .html.heex files, they are not considered. This can lead to a situation where if statements exist within a template that is not fully exercised by tests, but 100% test coverage is “achieved”.

I also recognize that having many conditionals or branches in a template might be an anti-pattern, but sometimes it seems like a quick way to implement some functionality. Ideally, I could rely on code coverage metrics to ensure those branches are hit.

I’ve observed this behavior using the basic mix test --cover, as well as using ExCoveralls as the project’s test_coverage.tool, in case that helps!

I hope there’s just some configuration option that I’ve missed.

Thanks!

4 comments

/phoenix #testing #code-coverage #excoveralls

1 1111 4

2024-03-11 07:12:38 UTC

Showing Posts 1 to 4

Show Best Posts
Show All (oldest first)
Show All (newest first)

thbar

I have the same question today ; the use case is as follows: I detected small errors introduced while migrating our templates to HEEX, and wanted to verify which heex files were ran through one test.

I will try to figure this out, but if you already managed to achieve that, I’m interested!

Post #1

thbar

I have created an issue here Is it possible to include HEEX files in the coverage? · Issue #288 · parroty/excoveralls · GitHub to give this problem a bit more visibility, since it looks important from a maintenance point of view.

Post #2

LostKobrakai

By my understanding cover works with modules. And templates are not modules, but external files converted into functions on a module. So I don’t think you can get line-by-line coverage for templates out of it. The other problem is that cover works based on compiled .beam files for elixir and it’s still an erlang tool, so it’s completely unaware of macros and what they do. So coverage around macro’ed code can be rather strange.

You could manually add lines like this to your view modules to get a per template coverage though:

def render("index.html", assigns), do: render_template("index.html", assigns)
[…]
def render(other, _assigns) do
  raise RuntimeError, "trying to render template #{other}, which has no explicitly defined render implementation"
end

That’s basically what phoenix generates for you, just explicitly defined for cover to deal with functions not generated by a macro. That does also only help for code calling render/2 and not render_template/2 directly. Phoenix by default calls render_template/2 only from render/2 and render_template is a private function, so it should be fine, but something to be aware of.

You could probably even put the raising function head to be generated by a macro, so it’s automatically part of your view modules and therefore forces people to explicitly define render functions.

Post #3

nivanson

Keeping the template code in a render function and checking to see if functional components gets called will give you some idea of coverage. This is useful for complicated template logic.