Add extension methods for Mock<T> setup on fixture customization

[ar3cka]

Add useful extension methods (CustomizeMock and FreezeMock) for Mock setup

[ploeh]

Thank you for your interest in contributing to AutoFixture. Could you share a scenario that demonstrates usage of one or two of these methods?

[ar3cka]

This is a typical test method with mock customization usage from our project:

[TestMethod]
public async Task OnlineServiceLicenseActivationService_WhenActivationFailedWithATemporalProblem_ReturnsRetryResult()
{
    // arrange
    var fixture = PrepareFixture();
    var command = fixture.Create<ActivateOnlineServiceLicense>();
    var activationResult = CreateErrorResult(LicenseActivationFailureReason.ActivationServiceTemporalProblem);

    fixture.CustomizeMock<ILicenseActivator>(mock => mock
        .Setup(activator => activator.ActivateAsync(
            It.IsAny<UserId>(),
            It.IsAny<LicenseId>(),
            It.IsAny<ActivationCode>()))
        .Returns(activationResult.YieldTask()));

    // act
    var service = fixture.Create<OnlineServiceLicenseActivationService>();
    var result = await service.ExecuteAsync(command);

    // assert
    Assert.IsTrue(result.Retry);
}

I can add more if you want, but they are almost the same.

[ploeh]

How is

fixture.CustomizeMock<ILicenseActivator>(mock => mock
    .Setup(activator => activator.ActivateAsync(
        It.IsAny<UserId>(),
        It.IsAny<LicenseId>(),
        It.IsAny<ActivationCode>()))
    .Returns(activationResult.YieldTask()));

better than

fixture.Customize<Mock<ILicenseActivator>>(c => c.Do(mock => mock
    .Setup(activator => activator.ActivateAsync(
        It.IsAny<UserId>(),
        It.IsAny<LicenseId>(),
        It.IsAny<ActivationCode>()))
    .Returns(activationResult.YieldTask())));

?

[ploeh]

FYI, I'm currently not reviewing pull requests for AutoFixture.

[zvirja]

Thanks for your efforts on making this PR!

I've reviewed your PR and would like to share my thoughts. In my opinion AutoFixture has very wide consumers range and it cannot provide helpers for all the cases out of the box. Rather, it's a set of building blocks and later users create their own usage patterns. The proposed helpers add very tiny value comparing to the native syntax, while they introduce yet another variance to achieve the same things.

Given that I'd vote to not include these changes. However, I'd like to ask @moodmosaic, @ecampidoglio and @adamchester to share their thoughts regarding this one.

@ar3cka Please let us know if you have some additional arguments we are missing.

[moodmosaic]

I agree with what @ploeh wrote and what @zvirja wrote.

[zvirja]

There are very few chances that this PR will be finally merged, so I'm closing it. Hope in future we'll have some sort of auxiliary project that could host such sort of things.

@ar3cka Thank you again for your contribution, time and efforts! If you have concerns regarding such a decision, please let us know.