Burlarse de los objetos en las pruebas JUnit: ¿práctica recomendada?

Question

¿Crees que burlarse de objetos en la prueba JUnit es una práctica excelente? No veo la gran ventaja. Claro que si tiene una base de datos que no debe ser considerada en su prueba, tiene sentido, pero ¿por qué no se acaba de inyectar otra implementación de ese componente (si se usa Spring)? Una fábrica de objetos para las pruebas lo haría mucho más fácil. No tengo mucha experiencia (estamos usando Mockito), pero ya lo he visto, ¡ese código de aplicación se modifica para que algunas propiedades se burlen! Los casos de prueba nunca deberían hacer tales cambios en el código productivo en mi opinión.

¿Qué piensas de este tema? ¿En qué casos te estás burlando de tu objeto o por qué no?

Answer 1

La idea de burlarse es aislar por completo lo que está probando. Luego, cuando falla la prueba, puede estar seguro de dónde está el problema sin tener que buscar en todo el árbol de dependencia de la clase. Si está probando el comportamiento de múltiples clases juntas, entonces esto no es realmente una prueba unitaria.

Una fábrica de objetos para las pruebas presumiblemente haría objetos con los métodos stubbed, y los marcos mocking son esencialmente fábricas de objetos genéricos para usar en las pruebas. Pero los simulacros proporcionan mucho más que los talones, una diferencia que Martin Fowler detalla aquí: http://martinfowler.com/articles/mocksArentStubs.html.

Si le parece una burla ardua, y también encuentra que la está haciendo mucho, ese es un ejemplo clásico de TDD que le dice que su diseño podría mejorarse.

Answer 2

ya he visto, que el código de aplicación se modifica de forma que algunas propiedades obtiene mockable! Los casos de prueba nunca deberían hacer tales cambios en el código productivo en mi opinión.

La idea central de TDD es que al obligar a hacer todo el código comprobable, el diseño en general será mejor. Esto no significa necesariamente que todo sea divisible, también podría significar reducir el acoplamiento para que se requiera menos burla.

Incluso si no está de acuerdo con esa filosofía (no la compro al 100%), siempre que crea que las pruebas automatizadas proporcionan valor, entonces tiene sentido cambiar el código de producción para respaldar ese valor (salvo compromete seriamente el diseño de alguna otra manera).

Answer 3

• Define calibrar clases de interfaces (descubrimiento interfaz)
• Permite superior al diseño de fondo
• aislamiento (prueba de la unidad)
• aclara las interacciones entre las clases
• veces la única manera para ver si objeto hace lo que quiere (Mocks and Tell Don’t Ask)
• Fomenta mejores pruebas estructuradas. Por ejemplo, jukito auto-inyecciones se burla para permitirte enfocarte en aquello en lo que confías quiere probar.
• permita conservar la encapsulación

• se reducen las dependencias

• Objeto de valor no debe ser burlado

marcos que imita grow-out de la necesidad. Como dijo Matthew Gilliard, si hay algún tipo de burla en marcha, entonces es señal de que el diseño se puede mejorar o la falta de enfoque de prueba. Las pruebas revelan muchos problemas en el código.

pero ¿por qué no se acaba de inyectar otra implementación de ese componente (si se usa un resorte)?

Tiene que escribir la implementación. Usando el marco de burla está hecho para ti.

¡Ya he visto que el código de la aplicación se modifica para que algunas propiedades se burlen! En mi opinión, los casos de prueba nunca deben esforzarse por dichos cambios en el código productivo.

Si mockable significa comprobable entonces es revés. Por ejemplo, en la prueba TDD define el código de producción.

Answer 4

Creo que la verdadera pregunta es si la prueba de la unidad es una buena práctica o no. Si usted cree que es así, el uso de burlarse de es una necesidad, desde el punto de vista de tener una unidad probada aislada de la implementación de sus dependencias.

Sin embargo, hay cierta confusión en la forma en que esto se relaciona con el concepto de capacidad de prueba. El código intrincado y complicado no es verificable esencialmente porque es difícil de entender. El código bien diseñado que tiene un diseño simple y limpio generalmente es más fácil de comprender y mantener; ¿Por qué debería ser difícil probar la unidad, entonces?

La confusión surge de ciertas limitaciones arbitrarias que se encuentran en algunas herramientas burlones, tales como la incapacidad para burlarse final o static métodos, o la necesidad de tener la unidad probada utilizar directamente objetos simulados creados en el código de prueba. Otras herramientas de burla no tienen estas limitaciones, y por lo tanto no requieren que "el código de la aplicación se modifique para que algunas propiedades se burlen". Con lenguajes de programación/plataformas modernos (Java, C#, Python, Ruby, etc.) todo es simulable; es solo cuestión de exponer este poder en una API burlona, ​​y ya se ha hecho para cada uno de esos idiomas (en aras de una divulgación completa, desarrollo una de esas herramientas).