shirishgoyal:

Currently actions for resources can be defined in separate modules using fragments (with use Spark.Dsl.Fragment). During testing, these modules show 0% coverage. What is the best way to improve coverage for them? Same also goes for all resource modules (with use Ash.Resource)

zachdaniel:

honestly? test coverage metrics are likely not useful or effective with Ash

zachdaniel:

you should ignore DSL modules

shirishgoyal:

okie got it

Eduardo B. Alexandre:

Can you elaborate on that? I understand the technical issue (with :cover unaware of macros), but I don’t get the useful part. I mean, the resources actions normally will contain all the business logic related to that resource. I think it is very helpfull to get a metric that will hint me if I tested all that logic or not.

zachdaniel:

The problem is that all of that code gets run through at compile time

zachdaniel:

So test coverage of thigns like ash resources would always be 0

zachdaniel:

not because they’re macros necessarily, but because it just produces data that gets passed to other code (that isn’t in your codebase) later on

zachdaniel:

Test coverage of things like custom changes/other functional integrations might still make sense

zachdaniel:

but you’ll want to separate them from your resources for that (i.e not using anonymous function syntax in the resource)