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