Arg.AnyType() for help with matching generic calls

[dtchepak]

From #152 (comment):

Stumbled upon this while attempting to validate a call into Microsoft.Extensions.Logging.ILogger.

The logger interface takes a T state, but the "public" APIs (i.e. common extension methods) do not expose this directly.

For example, consumer code calls it like this:

logger.Critical("A critical problem has occurred!");

This is translated into a call to the interface's method, which has this signature:

public void Log<TState>(
            LogLevel logLevel,
            EventId eventId,
            TState state,
            Exception exception,
            Func<TState, Exception, string> formatter)

The string parameter that represents the message in the original call is not passed directly into this method, but instead is wrapped in an internal type and passed as state. Thus, it is actually impossible to perform an assertion on ILogger, since you cannot specify the internal type without getting a compilation error.

I actually solved this before by creating an abstract TestableLogger that exposes a non-generic version of the base interface method and then redirecting the implementation to it, and then using .Received on top of that new method. Obviously, this is extremely convoluted.

I'd really appreciate if NSubstitute provided a way to specify Any<AnyType>() that would check for any generic argument on a given parameter.

[icalvo]

My workaround was to use Moq for this specific case 😉. Simpler, but I'd rather uninstall Moq for good! Please implement this, since I believe that ILogger substitutes should be quite a frequent use case that NSubstitute users are forced to implement by themselves.

In my case I just wanted a callback to output the state parameter so that I can see the logs in the test output. So it'd be fine if this feature also plays nice with Arg.Do.

[icalvo]

I did a tentative implementation of this issue, you can look at this draft PR: #715

It's not a ready PR because I took a compromise that maybe has a better solution and also because the AppVeyor build is failing. It seems that the latest PR (#711 by @alexandrnikitin) broke it somehow.

[edandersen]

Any chance this can be merged? With Moq currently self destructing this is the last thing holding many people back from using NSubstitute.

[dtchepak]

Hi @edandersen , I'll try to get to sort this out this weekend. Sorry for the delay.

[dtchepak]

Hi @icalvo ,

Sorry for how long it has taken for me to get to this. 😓

I think I have a fix for the AppVeyor build. Please cherry-pick from #724 and review that commit to make sure it looks ok.

[PieterJanse2001]

Any updates on this?

[icalvo]

Any updates on this?

I was on holiday, today I will take a look!

[icalvo]

@dtchepak Everything looks fine now, the build is passing so I think this is ready!

[akousmata]

Glad this is getting worked on! Any ETA on the publishing timeline for this set of changes? We are eagerly awaiting this feature 😄

[dtchepak]

@akousmata just waiting on review for 5.1.0.

Anyone that has time please take a look: #731

The PR updates CHANGELOG and bumps Castle.Core and System.Threading.Tasks.Extensions deps to latest versions, so no NSubstitute-internals knowledge required.

[alex289]

Hey @dtchepak, the PR seems to be completed. Is there a plan when the next Release is?

[dtchepak]

@alex289 just published 5.1.0 now, should be available on nuget as soon as nuget.org finishes indexing it.

[zlangner]

Since this issue is all about using NSubstitute to verify use of the ILogger, I'd like to let everyone know I have released NSubstitute.Community.Logging which aims to make this as easy as possible by providing extension methods that mirror the ILogger extension methods but they work with NSubstitute's Received/DidNotReceive methods. v0.0.1 is on nuget now