Would be nice to be able to ignore lines from coverage

[eseidelGoogle]

I'm not sure how one best would implement this (or if it's even possible), but there are certain lines of code in dart which are intentionally unreachable, an example of such is a private constructor.

class Colors {
   Colors._();
}

Which is a pattern used to make a class non-constructable. It's silly that coverage tells me that this line is uncovered:
https://coveralls.io/builds/9847810/source?filename=lib%2Fsrc%2Fmaterial%2Fcolors.dart

But I'm aware of no way with package:coverage to avoid that?

I could imagine a comment syntax, or maybe just teaching package:coverage about this specific idiom? Not sure.

This is not a high priority, but would be nice to have for projects trying for high line or file coverage numbers.

[jtmcdole]

What about @coverage(false) or @NotCovered

[eseidelGoogle]

I didn't know that was a thing. Thanks!

[jtmcdole]

It is not a thing, I was just suggesting a thing!

[eseidelGoogle]

Oh, sorry.

[eseidelGoogle]

The only downside of that, it that it likely means you have to incldue package:coverage as a dependency in your package, which seems suboptimal.

[jtmcdole]

Solid point & agreed. I was trying to use:

  void _();

And convert the class to abstract (its a static warehouse), but I'm getting warnings about it being unused in strong mode... which seems odd at first and then expected since it is private and nothing in the library is using it.

[zoechi]

or

// ignore: coverage

like used to suppress linter warnings

[cbracken]

It'd be a relatively substantial change to support driving this from the source level, since we don't look at it at all at the moment. All the data we need is available (in most cases) though.

Right now coverage collection doesn't look at the source at all, though it's available via the VM service so long as you're not running from a snapshot. When running from a snapshot, the VM will provide source reconstituted from the tokenised source (and line numbers will match up) but comments are stripped. I suspect that in most cases, it's reasonable to require that developers run from source rather than a snapshot for coverage, but that'll exclude dart: libraries for example. For such cases, we could support a path (or paths) to the code on disk and go from there.

I like the idea of doing it inline with the source since it reduces the likelihood of data getting out of date, compared to something like a list of ignored ranges, etc.

[cbracken]

On the specific issue here, it seems like a reasonable idea to identify a set of conditions under which code should be marked as non-coverable by default like the case @eseidelGoogle mentions above: private constructors with no invocations within the library.

[dnfield]

Would it make sense to have this be driven upstream by the observatory report? Perhaps having some kind of flag/attribute/comment the observatory could use to indicate that a file/class/method/set of lines are to be excluded.

[simc]

Is there any news on this feature? It would be really convenient 👍

[fatherOfLegends]

Please add this.