Objetos falsos codificados contra Mocking Framework

Question

Tengo curiosidad sobre qué método le gusta usar a la gente para burlarse y por qué. Los dos métodos que conozco están usando objetos falsos codificados y un marco burlón. Para demostrarlo, esbozaré un ejemplo usando C#.

Supongamos que tenemos una interfaz IEmployeeRepository con un método llamado GetEmployeeById.

public interface IEmployeeRepository 
{ 
    Employee GetEmployeeById(long id); 
} 

Podemos crear fácilmente una maqueta de este:

public class MockEmployeeRepository : IEmployeeRepository 
{ 
    public Employee GetEmployeeById(long id) 
    { 
     Employee employee = new Employee(); 
     employee.FirstName = "First"; 
     employee.LastName = "Last"; 
     ... 
     return employee; 
    } 
} 

Entonces, en nuestras pruebas podemos decir de forma explícita nuestros servicios para utilizar el MockEmployeeRepository, ya sea mediante una inyección incubadora o dependencia. Soy nuevo en los marcos de burla, así que tengo curiosidad de por qué los usamos, si podemos hacer lo anterior.

Answer 1

Eso no es un simulacro, es un trozo. Para el troquelado, su ejemplo es perfectamente aceptable.

Desde Martin Fowler:

Mocks son lo que estamos hablando aquí: objetos pre-programado con las expectativas que forman una especificación de las llamadas que se espera recibir.

Cuando se burla de algo, por lo general llama a un método de "Verificar".

mirada a esto para el diff entre burla y talones de http://martinfowler.com/articles/mocksArentStubs.html

Answer 2

Algunos distinguir entre burla y talones. Un objeto simulado puede verificar que ha sido interactuado de la manera esperada. Un marco de burla puede facilitar la generación de simulaciones y trozos.

En su ejemplo, ha apalabrado un único método en una interfaz. Considere una interfaz con n métodos, donde n puede cambiar con el tiempo. Una implementación cortada a mano puede requerir más código y más mantenimiento.

Answer 3

Tiendo a escribir trozos y burlas a mano, primero. Entonces, si se puede expresar fácilmente usando un marco de objeto simulado, lo reescribo para que tenga menos código para mantener.

Answer 4

Los he estado escribiendo a mano. Estaba teniendo problemas para usar Moq, pero luego leí TDD: Introduction to Moq, y creo que ahora entiendo lo que dicen acerca de los enfoques clásicos y mockistas. Voy a darle otra oportunidad a Moq esta tarde, y creo que entender el enfoque "burlón" me dará lo que necesito para que Moq funcione mejor para mí.

Answer 5

Una interfaz simulada puede tener diferentes salidas por prueba: una prueba puede tener un método devuelto nulo, otra prueba tiene el método devolver un objeto, otra prueba tiene el método arrojar una excepción. Todo esto está configurado en la prueba unitaria, mientras que su versión requeriría varios objetos escritos a mano.

psuedocode:

//Unit Test One 

MockObject.Expect(m => m.GetData()).Return(null); 

//Unit Test Two 

MockObject.Expect(m => m.GetData()).Return(new MyClass()); 

//Unit Test Three 

MockObject.Expect(m => m.GetData()).ThrowException(); 

Answer 6

Creo que la posibilidad de elegir entre escribir objetos ficticios a mano o mediante el uso de un marco depende mucho de los tipos de componentes que se está probando.

Si es parte del contrato para que el componente bajo prueba se comunique con sus colaboradores siguiendo un protocolo preciso, entonces los objetos simulados instrumentados ("Mocks") son lo que se debe usar. Con frecuencia, es mucho más fácil probar dichos protocolos utilizando un marco de burla que mediante codificación manual. Considere un componente que se requiere para abrir un repositorio, realizar algunas lecturas y escrituras en un orden prescrito, y luego cerrar el repositorio, incluso frente a una excepción. Un marco de burla facilitaría la configuración de todas las pruebas necesarias. Las aplicaciones relacionadas con las telecomunicaciones y el control de procesos (para elegir un par de ejemplos aleatorios) están llenas de componentes que deben probarse de esta manera.

Por otro lado, muchos componentes en aplicaciones comerciales generales no tienen restricciones particulares sobre cómo se comunican con sus colaboradores. Considere un componente que realiza algún tipo de análisis de, digamos, cargas de cursos universitarios. El componente necesita recuperar información del instructor, estudiante y curso de un repositorio. Pero no importa el orden en que recupera los datos: instructor-alumno-curso, alumno-curso-instructor, todo a la vez, o lo que sea. No es necesario probar y aplicar un patrón de acceso a datos. De hecho, sería perjudicial probar ese patrón, ya que exigiría una implementación particular innecesariamente. En este contexto, los objetos ficticios simples no instrumentados ("Stubs") son adecuados y un marco de burla es probablemente excesivo.

Debo señalar que incluso cuando se corta, un marco puede hacer que su vida sea mucho más fácil. Uno no siempre tiene el lujo de dictar las firmas de sus colaboradores. Imagine pruebas unitarias de un componente que se requiere para procesar datos recuperados de una interfaz gruesa como IDataReader o ResultSet. El troquelado a mano de tales interfaces es, en el mejor de los casos, desagradable, especialmente si el componente bajo prueba solo utiliza tres de los innumerables métodos en la interfaz.

Para mí, los proyectos que han requerido marcos de burla casi siempre tienen una naturaleza de programación de sistemas (por ejemplo, proyectos de infraestructura web o de base de datos, o plomería de bajo nivel en una aplicación comercial). Para proyectos de programación de aplicaciones, mi experiencia ha sido que había pocos simulacros a la vista.

Teniendo en cuenta que siempre nos esforzamos por ocultar los detalles de la infraestructura de bajo nivel desordenado tanto como sea posible, parece que deberíamos aspirar a que los stubs simples superen con creces a los simulacros.