¿Qué debo burlarme en las pruebas de una aplicación con nivel de servicio y nivel DAO?

8

Mis clases siguen esta estructura.

Nivel de servicio (crea y asigna InputDTO a datos de base de datos)
Nivel DAO (en realidad ejecuta llamadas DB)

Cuando escribo pruebas JUnit de nivel de servicio, se llama al nivel DAO, y esto espera una conexión de base de datos real y obtener datos de la base de datos.

¿Debería burlarme completamente del nivel DAO del nivel de servicio, o debería burlarme de la conexión de la base de datos y los datos recibidos de la base de datos?

En segundo lugar, la aplicación espera ciertos datos de un caché.

Para el tiempo de ejecución de JUnit, no hay caché, entonces, ¿cómo se debe manejar esto? El método de nivel de servicio incluye buscar el caché para obtener los detalles.

— bicicleta nueva brillante
fuente

9

Voy a hablar sobre los dobles de prueba, si no se han encontrado con este término, entonces probablemente querrán leer primero el enlace del artículo de Martin Fowler .

Para la prueba de base de datos - Si usted está siguiendo una pura enfoque de prueba Unidad continuación, se utilizaría un código auxiliar o una Mock tipo de prueba dobles para burlarse de la conexión DB y sus respuestas. Si está utilizando un simulacro , le recomendaría utilizar Mockito, JMock o su otra herramienta de imitación favorita. Sin embargo, esto es bastante laborioso cuando se trata de probar un gran recurso de terceros, como una base de datos.
Para las pruebas de la base de datos: si está siguiendo una definición un poco más flexible de pruebas unitarias, entonces podría usar una Prueba falsa doble. En su caso particular, esta sería una base de datos en memoria como HSQL. Esta es una forma muy popular de 'unidad' probando su capa de base de datos. Algunos argumentarán que esto no es una prueba unitaria y que, en cambio, es una prueba de integración. Creo que en realidad está bien, el hecho es que tienes algunas pruebas que eliminan tu código :-)
Para la prueba de caché: es probable que un amigo de estilo Stub de Test Double sea su amigo aquí, dependiendo de cuán compleja sea la API de caché.

HTH!

— Martijn Verburg
fuente

3

Hermosa respuesta, nuestra idea es el enfoque de prueba de unidad pura, tratando de no crear pruebas de integración grandes, sino pruebas de unidades más pequeñas . No estaba al tanto del término Prueba de Dobles, gracias

— shinynewbike

2

+1 siempre favorece la forma más pequeña y sencilla de ejercer el código específico con el que está trabajando. A medida que el sistema crece, introduzca pruebas de integración / funcional / sistema para que actúen como indicadores rápidos de fallas.

— Gary Rowe

1

+1 Por mencionar a Mockito. Es, con mucho, el marco de simulación más intuitivo que he usado en cualquier idioma, e incluso tiene características ingeniosas que reducen el dolor de forzar retroactivamente en las pruebas unitarias al código heredado que nunca se diseñó originalmente con las pruebas unitarias en mente. El objeto Mockito Spy es increíblemente útil para esto.

— maple_shaft

El término "prueba unitaria" actualmente se usa más comúnmente para describir las características técnicas de una prueba: una prueba unitaria es una prueba que se ejecuta rápidamente y sin requisitos previos. El término "prueba de integración", cuando se usa correctamente, describe el propósito de la prueba: probar la integración de las partes. Por lo tanto, una "prueba unitaria" puede ser fácilmente una "prueba de integración" si prueba alguna integración y se ejecuta rápidamente.

— Oberlies

2

En resumen, la respuesta es bastante simple.

Tienes tres capas

[El caso de prueba] -> [El comportamiento bajo prueba] -> [Los colaboradores utilizados por ese comportamiento]

La tercera capa es lo que debe ser burlado. Por ejemplo:

la PokemonCaptureServiceTest;
las pruebas PokemonCaptureService;
que usa Pokeball

En este ejemplo, resulta que Pokeballes una lógica de terceros. Requiere todo tipo de fontanería, como conexiones de bases de datos y archivos de propiedades, etc. Confía en que su tercero lo haya probado adecuadamente, por lo que le gustaría omitirlo de su prueba de PokemonCaptureService. Por lo tanto, debe ser burlado.

Sin embargo, en otro momento y lugar, el colaborador Pokeballes una clase simple que introduce muy poca complejidad en el caso de prueba y puede incluirse fácilmente en la prueba. En este caso, puede decidir incluir una instancia real de Pokeballen la PokemonCaptureServiceinstancia que se está probando.

No hay una regla dura y rápida. Depende de usted diseñar sus pruebas de la manera que le parezca mejor. Su objetivo es crear pruebas correctas y mantenibles lo más rápido posible. La experiencia es clave aquí. Escriba más pruebas y muy pronto obtendrá una buena intuición para ello.

— Synesso
fuente

0

Es difícil saber qué es exactamente lo que quieres probar porque, a juzgar por la pregunta, estás por todas partes. Por lo tanto, es difícil darle algún ejemplo práctico sobre cómo proceder que no sea llevarlo a artículos sobre cómo burlarse de cosas. Por lo tanto, debe ser más específico y dividir un poco las cosas:

¿Quieres probar para que el caché funcione correctamente?
¿Quieres probar alguna llamada de DB en particular?
¿Desea probar la aplicación para que esté usando el caché correctamente?

Una vez que decida exactamente cuál es la unidad que desea probar, entonces seleccionar qué hacer es fácil: en una prueba de unidad pura, todo menos la "unidad bajo prueba" debe ser burlado. La razón detrás de esto es que puede estar seguro de sus expectativas de instalación en los simulacros de que la unidad probada funciona como debería.

Aparte de eso, es posible que desee escribir algunas pruebas en JUnit que son pruebas de integración, es decir, usar menos simulacros. Incluso si se usan como comprobaciones de cordura para ver si el diseño del software es correcto, debe tener en cuenta que serán frágiles y no siempre darán ningún indicador sobre qué es exactamente lo que está mal con su aplicación o sistema.

— Spoike
fuente