Simulacros de clases .NET que utilizan clases contenedoras

Question

Tengo una clase que toma una instancia de MethodInfo y extrae algo de información de ella, pero me gustaría simular esta clase. Por el momento es difícil porque requiere un MethodInfo, por lo que mi plan era crear un contenedor para la clase MethodInfo e implementar una interfaz en él. Por ejemplo:

public interface IMethodInfo 
{ 
    string Name { get; } 
} 

public class MethodInfoProxy : IMethodInfo 
{ 
    private readonly MethodInfo _method; 
    public MethodInfoProxy(MethodInfo method) 
    { 
     _method = method; 
    } 

    public string Name { get { return _method.Name; } } 
} 

public class MyClass 
{ 
    public MyClass(IMethodInfo method) 
    { 
     ... 
    } 
} 

Otro ejemplo sería el método File.Exists. El pensamiento sería crear un IFile.Exists y ponerlo en una clase FileProxy que simplemente delegaría a File.Exists.

Como soy nuevo en el mundo entero de pruebas de unidades, me gustaría saber si esto se consideraría un buen enfoque para tomar.

Answer 1

Usted tiene dos opciones:

1. utilizar un marco de burla como Microsoft Moles o TypeMock Isolator que pueden burlarse de clases estáticas y sellados. Esto es genial porque no termina cambiando su código solo para aislar el código bajo prueba de sus dependencias.
2. Definición de interfaces para comportamientos que desea simular y, a continuación, creación de una implementación predeterminada que envuelve una llamada estática u otra API difícil de probar. Este es el enfoque que ha sugerido y uno que he usado mucho. La clave, al definir estas interfaces es pasar la implementación real/simulada de la interfaz en la clase de prueba a través de alguna forma de dependency injection, generalmente inyección de constructor.Algunas personas cometen el error de construir el objeto dentro de la clase que se prueba y eso hace que sea imposible probarlo. Una buena regla general es que cuando ve objetos que se construyen en su código comercial, entonces ese es un olor a código, no siempre es algo malo, pero definitivamente algo que ver con sospecha. Hay un gran video sobre esto: The Clean Code Talks - "Global State and Singletons".

Hay una pequeña guerra religiosa entre los que piensan que las pruebas no deberían cambiar el código y las que creen que deberían hacerlo. La inyección de dependencia, que es esencial si se va a burlar mediante la creación de interfaces, conduce a un código con alta cohesión y acoplamiento flexible y una API intuitiva. Pero el otro enfoque no está excluido de estos beneficios, simplemente no es tan automático.

Answer 2

Puede crear un contenedor alrededor de cada clase que use, pero sería extremadamente costoso. Es mejor utilizar un marco de burla como el marco de topo por Microsoft http://research.microsoft.com/en-us/projects/pex/ que también puede anunciar métodos estáticos.

Answer 3

Una clase falsa (o una clase falsa) sería una clase que usted hace para satisfacer las dependencias y hacer que su prueba sea más determinista al descartar problemas en sus dependencias.

public interface IMethodInfo 
{ 
    string Name { get; } 
} 

Su clase simulada:

FakeMethodInfo : IMethodInfo 
{ 
string Name {get {return "FakeMethod";}} 
} 

Ahora, en su prueba de unidad, pasar la clase FakeMethodInfo donde se necesita un IMethodInfo.

Todo el propósito es que usted sabe FakeMethodInfo simplemente devuelve una cadena por lo que si algo falla, es no es el problema.

---

No sé qué contexto tiene MethodInfo en su programa. Un mejor ejemplo sería

interface IUser 
{ 
string UserName {get;} 
} 

Si se implementara en una clase, obtendría el nombre de usuario real de una base de datos.

Ahora, si hace una falsa, y la pasa, simula un usuario conectado sin un usuario real, y descarta que cualquier problema tenga que ver con `IUser.

Consulte esta gran respuesta que publiqué sobre por qué utilizaría la burla. Y un ejemplo con Moq .:

Difference between Dependency Injection and Mocking framework (Ninject vs RhinoMock or Moq)

Answer 4

Recomiendo tratar de sacar las dependencias de la clase, en lugar de proporcionar un MethodInfo (o un proxy), solo suministre el Name.

Cuando eso no es práctico, puede escribir clases de proxy que utilizan una interfaz de adaptador (como ha sugerido) o utilizar una herramienta de magia negra como TypeMock o Moles (es broma sobre la parte de magia negra: I simplemente no tengo ninguna experiencia con ellos).

Si va a utilizar el enfoque de proxy, asegúrese de echar un vistazo a la biblioteca SystemWrapper, que ya maneja unas veinte clases del .NET framwork.

Answer 5

Para una creación más rápida de clases de contenedor, puede usar uno de los generadores de código de Andamios que creé.

https://www.nuget.org/packages/Digitrish.WrapperGenerator/

Esto generará interfaz que se puede utilizar para cualquier marco de burla y clase contenedora concreta para la aplicación real.