Clases burlonas que no tienen interfaz e incluso ningún método virtual

Question

Quiero burlarme de un método particular de una clase, el problema al que me enfrento es que la clase no tiene ninguna interfaz y también ese método no es virtual.

¿Alguien puede sugerir otra forma de implementar la burla?

Cualquier ayuda será apreciada. Gracias de antemano

Answer 1

Sugiero refactorizar su código;) Todos los marcos burladores que crean simulacros derivando de una clase simulada requieren que los métodos sean virtuales (esto es más un requisito de CLR en lugar de un marco burlón).

Para burlarse de los métodos no-virtuales que se pueden utilizar marcos basados ​​en los perfiladores como lunares o Typemock aislador, sin embargo, esto requiere para funcionar corredor de prueba usando corredor especial que fije perfiles CLR para procesar

Answer 2

Existen marcos de prueba de unidades como TypeMock Isolator que le permiten simular miembros no virtuales.

Answer 3

Opción 1: TypeMock Isolator o algo similar, lo que permite una confusión más profunda con el código que la burla normal.

Opción 2: (Preferido si es posible) Modificar el diseño, p. mediante la introducción de una interfaz y la creación de una implementación de delegación que simplemente invoca a la clase antipática existente. Luego puede depender de la interfaz, simularla en pruebas y delegar en la implementación "real" para producción.

Esto supone que realmente debería burlarse de la clase, por supuesto. No debe burlarse automáticamente de todo que usa su código. Tiendo a pensar en burlarse de "servicios" de alguna descripción, mientras que no me burlaría (por ejemplo) List<T>.

Answer 4

burlarse puramente por una herencia clase I haría lo siguiente:

1. Crear una interfaz que contenga los ÚNICOS miembros públicos que pretendo utilizar. por ej.

   public interface IDbContext { 
       int SaveChanges(); 
   } 
   

2. Si la clase de legado de destino se selló a continuación, que crearía una clase de proxy/decorador que implementa la nueva interfaz y simplemente invocar los métodos/propiedades subyacentes.

   public class MyDbContextProxy : IDbContext { 
       DbContext _context = null; 
       public MyDbContextProxy(DbContext interceptedContext) { 
        _context = interceptedContext; 
       } 
       // decorated method 
       public int SaveChanges() { 
        _context.SaveChanges(); 
       } 
   } 
   

3. Si la clase de legado de destino no está sellado que crearía un descendiente del objetivo e implementar la interfaz. La clase auto se adhiere a la interfaz.

   public class MyDbContextProxy : DbContext, IDbContext { 
       // child adheres to interface by inheritence 
   } 
   

Ahora se puede Mock cabo IDbContext.

Answer 5

Ahora mismo hay algo así como Fakes Framework en VS2012. Es el sucesor de Moles (también es capaz de simular clases, etc., como TypeMock). Está disponible solo en la edición Ultimate, así que no creo que valga la pena el precio de Ultimate.

Pero me gustaría hablar sobre el problema con las clases de burla desde otra perspectiva.

¿Es un buen enfoque para simular clases en lugar de interfaces o es una especie de mal olor? Nunca he usado TypeMock (es demasiado costoso siquiera considerarlo en una empresa pequeña), pero la gente dice que es un poco "demasiado poderoso", por lo que me gustaría usar Moq/RhinoMocks, pero a veces me gustaría burlarme o simular. un método y deja a los demás. ¿Es mi mala forma de pensar acerca de los métodos de burla/simulación durante las pruebas? o a veces se requiere?