Ignore branches pattern

[Zubastic]

Hello. We trying to use coverage but having issue. Used Dependency injections + dependency chains, so this code is common for project:

    public sealed class Extension : ExtensionBase
    {
        #region Fields

        private readonly IUnityContainer container;

        #endregion

        #region Constructors

        public Extension (IUnityContainer container)
        {
            this.container = container;
        }

        #endregion

        #region Base overrides

        public override async Task AfterRequest(IExtensionContext context)
        {
            if (!context.Response.ValidationResult.IsSuccessful())
            {
                return;
            }
            // here some stuff
        }

        #endregion
    }

So I didn't check IsSuccessful branch because it is not common. How I could ignore some patterns? Or change percentage of coverage, ignoring this checks.

Also another common problem that we use Registrator classes like this:

    [Registrator]
    public sealed class Registrator : RegistratorBase
    {
        public override void RegisterUnity()
        {
            this.UnityContainer
                .RegisterType<Extention>(new ContainerControlledLifetimeManager())
                ;
        }

        public override void RegisterExtensions(IExtensionContainer extensionContainer)
        {
            extensionContainer
                .RegisterExtension<IExtension, Extension>(x => x
                .WithUnity(this.UnityContainer))
                ;
        }
    }

They are called every time and having Registrator attribute. How we could ignore them? Thanks!

[MarcoRossignoli]

At the moment we can skip instrumentation using attributes and files filter. But we don't have a way to avoid instrumentation/coverage of body part.

To allow that we should provide some trick like parse some fake empty debug only method like this.DisableCoverletInstrumentation()/this.EnableCoverletInstrumentation or better add a config where a user provide filename(cs)/range rows to skip.

I dunno if other guys has got other ideas @petli @tonerdo

Anyway strange request(first time), I mean it's ok a non 100% coverage.

[petli]

If 100% code coverage is important to the code in question, a workaround is to move the logic that should be tested into a separate method and tag the entry point with its precondition checks to be excluded from testing:

    [ExcludeFromCodeCoverage]
    public override async Task AfterRequest(IExtensionContext context)
    {
        if (!context.Response.ValidationResult.IsSuccessful())
        {
            return;
        }

        await DoAfterRequest(context);
    }

    private async Task DoAfterRequest(IExtensionContext context)
    {
         // here some stuff
    }

A full solution for this kind of things could be an attribute on the IsSuccessful() method like [ExpectsToReturn(true)], which collapses the condition and branch point by not considering the unexpected case. Not trivial to implement though, since it would require analysing the expression in the if statement to see what it would evaluate to. Are there maybe some hints like this already that are used to guide the compiler, and that leaves enough traces in the IL that can be detected by the instrumentor?

[MarcoRossignoli]

I see annotation related only to nullability https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/attributes/nullable-analysis (MaybeNullWhen etc...)

[petli]

An easier thing to implement is to provide a couple of static wrapper methods that this kind of code can use, and then just check for the top-level usage of those in the if conditions:

if (SkipCoverage.ForTrue(!context.Response.ValidationResult.IsSuccessful()))
{
    return;
}

Could also be extended to exception handlers:

try
{
    ...
}
catch (Exception e) when SkipCoverage.ForException
{
    ...
}

The defintions of these would be something like:

public static class SkipCoverage
{
    public const bool ForException = true;

    public bool ForTrue(bool value) => value;
}

[github-actions[bot]]

This issue is stale because it has been open for 3 months with no activity.