Excluding calls originating from a specific function/binary. Is it possible?

[JelkeH]

Some of the code we want to test needs quite some setup in the form of a created instance (mocking is not sufficient due to all the relations needed and checked. Mocking would mostly result in testing the mocks). We would like to include the coverage these tests generate. however This poses the following problem: The code used to generate the instances is also seen as coverage.
I would like to exclude this.

I have (simplified) following setup:

Projects:

• CodeToTest
• Tests
• CodeToGenerateInstances

I would like to measure the coverage in CodeToTest for tests in 'Tests'. However I would like to exclude all coverage measured due to calls originating from CodeToGenerateInstances (which are used by the setup in some tests )

Would such be possible?

[daveMueller]

Isn't it possible for you to realize this with a filter expression on the CodeToGenerateInstances projects? (https://github.com/coverlet-coverage/coverlet/blob/master/Documentation/MSBuildIntegration.md#filters)

[daveMueller]

OK now I understand the question. Coverlet is doing static code instrumentation which means that the tracker is injected into all resolved assemblies before the tests are running. While the tests are being executed coverlet basically just collects how often the tracker was hit and afterwards generates a report out of those results.
Now to realize such a use case we would need to analyze which code of CodeToTest is called by CodeToGenerateInstances and exclude it from the instrumentation or somehow filter it out afterwards when the reports get generated. From my point of view this would require a detailed preprocessing analysis of the source code which coverlet isn't doing. Depending on the source code this most likely could also lead to a big performance drop.
The other idea with the start-coverage and end-coverage is interesting. But as coverlet doesn't support dynamic instrumentation this also seems not really possible to me. At the time the tests get executed, the assemblies already have been instrumented and thus we are not able to figure out what are the parts of the code that should be checked for coverage.
@tonerdo @MarcoRossignoli @petli Any other thoughts on this?

[MarcoRossignoli]

I agree with @daveMueller we statically instrument and we don't analyze the code flow. The only way we have to exclude classes is to use the Exclude filter or the exclude attribute at class or member level.

[JelkeH]

So a tracker is inserted at every line of code to be able to track it's execution, Am I correct?
Would it be possible to create something like a global flag to enable/disable the trackers globally?
The flags could be switched around the Act part of each test (this could possible even be injected).
Probably I overlook a lot off difficulties, but I'm most of all curious of such direction could possibly work .

[daveMueller]

So a tracker is inserted at every line of code to be able to track it's execution, Am I correct?

coverlet injects the tracker at sequence points in the IL which most of the time corresponds to line and column numbers.

Would it be possible to create something like a global flag to enable/disable the trackers globally?

Maybe yes this could work to enable/disabled the tracker that collects the line/branch hits. But as @MarcoRossignoli already mentioned, we don't analyze the code flow. So we wouldn't really know if a line wasn't hit because it wasn't planned to be covered or because of a test not executing the code.

[JelkeH]

Conceptually, if you would have the tracker disabled by default and enable/disable it before/after the 'act' of each test, you could be able to track only code executed due to an act right?