Deridere i metodi di estensione con Moq

Ho un'interfaccia preesistente ...

public interface ISomeInterface
{
    void SomeMethod();
}

e ho esteso questa intreface usando un mixin ...

public static class SomeInterfaceExtensions
{
    public static void AnotherMethod(this ISomeInterface someInterface)
    {
        // Implementation here
    }
}

Ho una lezione che si chiama così e che voglio testare ...

public class Caller
{
    private readonly ISomeInterface someInterface;

    public Caller(ISomeInterface someInterface)
    {
        this.someInterface = someInterface;
    }

    public void Main()
    {
        someInterface.AnotherMethod();
    }
}

e un test in cui mi piacerebbe deridere l'interfaccia e verificare la chiamata al metodo di estensione ...

    [Test]
    public void Main_BasicCall_CallsAnotherMethod()
    {
        // Arrange
        var someInterfaceMock = new Mock<ISomeInterface>();
        someInterfaceMock.Setup(x => x.AnotherMethod()).Verifiable();

        var caller = new Caller(someInterfaceMock.Object);

        // Act
        caller.Main();

        // Assert
        someInterfaceMock.Verify();
    }

L'esecuzione di questo test genera tuttavia un'eccezione ...

System.ArgumentException: Invalid setup on a non-member method:
x => x.AnotherMethod()

La mia domanda è: c'è un modo carino per deridere la chiamata del mixin?

Non è possibile "direttamente" deridere il metodo statico (quindi il metodo di estensione) con il framework di derisione. Puoi provare Moles ( http://research.microsoft.com/en-us/projects/pex/downloads.aspx ), uno strumento gratuito di Microsoft che implementa un approccio diverso. Ecco la descrizione dello strumento:

Moles è un framework leggero per stub di test e deviazioni in .NET basato su delegati.

Le talpe possono essere utilizzate per deviare qualsiasi metodo .NET, inclusi metodi non virtuali / statici in tipi sigillati.

Puoi utilizzare Moles con qualsiasi framework di test (è indipendente al riguardo).

Ho usato un wrapper per aggirare questo problema. Crea un oggetto wrapper e passa il tuo metodo deriso.

Vedi Metodi statici beffardi per i test unitari di Paul Irwin, ha dei buoni esempi.

Ho scoperto che dovevo scoprire l'interno del metodo di estensione per cui stavo cercando di deridere l'input e deridere cosa stava succedendo all'interno dell'estensione.

Ho visto l'utilizzo di un'estensione come aggiunta di codice direttamente al tuo metodo. Ciò significava che dovevo deridere ciò che accade all'interno dell'estensione anziché l'estensione stessa.

Puoi deridere un'interfaccia di test che eredita da quella reale e ha un membro con la stessa firma del metodo di estensione.

È quindi possibile prendere in giro l'interfaccia di test, aggiungere quella reale alla simulazione e chiamare il metodo di prova nell'impostazione.

L'implementazione del mock può quindi chiamare qualunque metodo tu voglia o semplicemente controllare che il metodo sia chiamato:

IReal //on which some extension method is defined
{
    ... SomeRegularMethod(...);
}

static ExtensionsForIReal
{
    static ... SomeExtensionMethod(this IReal iReal,...);
}

ITest: IReal
{
    //This is a regular method with same name and signature as the extension without the "this IReal iReal" parameter
    ... SomeExtensionMethod(...);
}

var someMock = new Mock<ITest>();
Mock.As<IReal>(); //ad IReal to the mock
someMock.Setup(x => x.SomeExtensionMethod(...)).Verifiable(); //Calls SomeExtensionMethod on ITest
someMock.As<IReal>().Setup(x => x.SomeRegularMethod(...)).Verifiable(); //Calls SomeRegularMethod on IReal

Grazie alla soluzione Håvard S in questo post per come implementare una simulazione che supporta due interfacce. Una volta l'ho trovato, adattandolo con l'interfaccia di test e il metodo statico è stata una passeggiata.

Puoi facilmente deridere un metodo di estensione con JustMock . L'API è la stessa del metodo normale beffardo. Considera quanto segue

public static string Echo(this Foo foo, string strValue) 
{ 
    return strValue; 
}

Per organizzare e verificare questo metodo, utilizzare quanto segue:

string expected = "World";

var foo = new Foo();
Mock.Arrange(() => foo.Echo(Arg.IsAny<string>())).Returns(expected);

string result = foo.Echo("Hello");

Assert.AreEqual(expected, result);

Ecco anche un link alla documentazione: Metodi di estensione Derisione

Mi piace usare il wrapper (modello adattatore) quando sto avvolgendo l'oggetto stesso. Non sono sicuro che lo userei per avvolgere un metodo di estensione, che non fa parte dell'oggetto.

Uso una proprietà iniettabile pigra interna di tipo Action, Func, Predicate o delegato e consento l'iniezione (sostituzione) del metodo durante un test unitario.

    internal Func<IMyObject, string, object> DoWorkMethod
    {
        [ExcludeFromCodeCoverage]
        get { return _DoWorkMethod ?? (_DoWorkMethod = (obj, val) => { return obj.DoWork(val); }); }
        set { _DoWorkMethod = value; }
    } private Func<IMyObject, string, object> _DoWorkMethod;

Quindi si chiama Func anziché il metodo effettivo.

    public object SomeFunction()
    {
        var val = "doesn't matter for this example";
        return DoWorkMethod.Invoke(MyObjectProperty, val);
    }

Per un esempio più completo, consulta http://www.rhyous.com/2016/08/11/unit-testing-calls-to-complex-extension-methods/

Quindi se stai usando Moq e vuoi deridere il risultato di un metodo Extension, allora puoi usare SetupReturnsDefault<ReturnTypeOfExtensionMethod>(new ConcreteInstanceToReturn())l'istanza della classe mock che ha il metodo di estensione che stai cercando di deridere.

Non è perfetto, ma per scopi di test unitari funziona bene.