beffardo Metodi di estensione con Moq

Question

ho un'interfaccia preesistente ...

public interface ISomeInterface 
{ 
    void SomeMethod(); 
} 

e ho esteso questo intreface utilizzando un mixin ...

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

ho un i thats classe di chiamare questo che voglio provare ...

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 prendere in giro 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(); 
    } 

eseguire questo test tuttavia genera un'eccezione ...

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

La mia domanda è: esiste un bel modo per deridere la chiamata mixin?

Answer 1

Non è possibile "simulare" direttamente il metodo statico (quindi il metodo di estensione) con la struttura di simulazione. 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 prova e deviazioni in .NET che si basa sulla delegati.

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

È possibile utilizzare Moles con qualsiasi framework di testing (è indipendente a tale proposito).

Answer 2

Ho utilizzato un wrapper per ovviare a questo problema. Crea un oggetto wrapper e passa il tuo metodo mocked.

Vedere Mocking Static Methods for Unit Testing di Paul Irwin, ha alcuni esempi.

Answer 3

Mi piace utilizzare l'involucro (modello adattatore) quando sto avvolgendo l'oggetto stesso. Non sono sicuro di usarlo per avvolgere un metodo di estensione, che non fa parte dell'oggetto.

Uso una proprietà Lazy Injectable interna di entrambi i tipi Action, Func, Predicate o delegate e consente di iniettare (swapping out) il 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 invece del metodo effettivo.

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

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

Answer 4

ho scoperto che ho dovuto scoprire l'interno del metodo di estensione che stavo cercando di deridere l'input per e finto che cosa stava succedendo all'interno del estensione.

Ho visto è come le estensioni sono statici, che è come mettere il codice direttamente nel metodo, quindi è necessario prendere in giro ciò che accade all'interno dell'estensione piuttosto che l'estensione stessa.