burlando de métodos de extensión con Moq

Question

que tienen una interfaz preexistente ...

public interface ISomeInterface 
{ 
    void SomeMethod(); 
} 

y he ampliado esta intreface utilizando un mixin ...

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

que eso es tener una clase de llamar a este que quiero probar ...

public class Caller 
{ 
    private readonly ISomeInterface someInterface; 

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

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

y una prueba en la que me gustaría burlarse de la interfaz y verificar la llamada al método de extensión ...

[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(); 
    } 

Al ejecutar esta prueba, sin embargo genera una excepción ...

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

Mi pregunta es, ¿hay una buena manera de burlar a cabo la llamada mixin?

Answer 1

No se puede "directamente" método estático mock (de ahí método de extensión) con burlarse marco. Puede probar Moles (http://research.microsoft.com/en-us/projects/pex/downloads.aspx), una herramienta gratuita de Microsoft que implementa un enfoque diferente. Aquí está la descripción de la herramienta:

Moles es un marco ligero para talones de prueba y desvíos en .NET que se basa en los delegados.

Moles se puede utilizar para desviar cualquier método NET, incluyendo métodos no virtuales/estáticas en tipos sellados.

Puede usar Moles con cualquier marco de prueba (es independiente de eso).

Answer 2

he utilizado una envoltura de solucionar este problema. Crea un objeto envoltorio y pasa tu método burlado.

Ver Mocking Static Methods for Unit Testing por Paul Irwin, tiene buenos ejemplos.

Answer 3

me gusta usar la envoltura (adapter) cuando estoy envolviendo el objeto en sí. No estoy seguro de que use eso para envolver un método de extensión, que no es parte del objeto.

Uso una propiedad Inyectable Lazy interna de cualquier tipo Acción, Func, Predicado o delegar y permitir la inyección (intercambio) del método durante una prueba unitaria.

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; 

Luego llama al Func en lugar del método real.

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

Para un ejemplo más completo, echa un vistazo a http://www.rhyous.com/2016/08/11/unit-testing-calls-to-complex-extension-methods/

Answer 4

me di cuenta que tenía que descubrir el interior del método de extensión que estaba tratando de burlarse de la entrada para, y se burlan de lo que estaba pasando dentro de la extensión.

yo veía es como extensiones son estáticas, que es como poner el código directamente en su método, por lo que necesita para burlarse de lo que sucede dentro de la extensión en lugar de la propia extensión.