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

7

Mis clases están siguiendo 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 de 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 estar burlándome del nivel DAO completamente 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 debería manejarse esto? El método de nivel de servicio incluye buscar el caché para obtener los detalles.

    
pregunta shinynewbike 10.11.2011 - 10:26

3 respuestas

9

Voy a hablar acerca de los Dobles de prueba, si no has encontrado este término, entonces probablemente quieras leer El artículo de Martin Fowler enlaza primero.

  • Para la prueba de la base de datos: si está siguiendo un enfoque de prueba de unidad pura , entonces usaría un Stub o un Mock Tipo de prueba doble para simular la conexión DB y sus respuestas. Si está utilizando un Mock , le recomiendo que utilice Mockito, JMock o su otra herramienta de burla 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 tanto más flexible de las pruebas unitarias, entonces podría usar una prueba doble Fake . En su caso particular, esta sería una base de datos en memoria como HSQL. Esta es una forma muy popular de "unidad" para probar su capa de base de datos. Algunos argumentarán que esto no es una prueba de unidad, y que en su lugar es una prueba de integración. Creo que está bien, el hecho es que tiene algunas pruebas que eliminan su código :-)

  • Para las pruebas de caché: un estilo de Stub de Test Double es probable que sea tu amigo aquí, dependiendo de lo compleja que sea la API de caché.

HTH!

    
respondido por el Martijn Verburg 10.11.2011 - 11:10
2

En el 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:

  1. el PokemonCaptureServiceTest ;
  2. pruebas PokemonCaptureService ;
  3. que utiliza Pokeball

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

Sin embargo, en otro tiempo y lugar, el colaborador Pokeball es una clase simple que introduce muy poca complejidad en el caso de prueba y se puede incluir fácilmente en la prueba. En este caso, puede decidir incluir una instancia real de Pokeball en la instancia PokemonCaptureService 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í. Escribe más pruebas & muy pronto obtendrás una buena intuición para ello.

    
respondido por el Synesso 11.11.2011 - 01:34
0

Es difícil decir qué es exactamente lo que quieres probar porque a juzgar por la pregunta, estás por todos lados. Por lo tanto, es difícil darte un ejemplo práctico sobre cómo proceder además de llevarte a artículos sobre cómo burlarte de cosas. Así que necesitas ser más específico y dividir las cosas un poco:

  • ¿Desea realizar una prueba para que el caché funcione correctamente?

  • ¿Quieres probar alguna llamada de DB en particular?

  • ¿Desea probar la aplicación para que use la memoria caché correctamente?

Una vez que decidas exactamente cuál es la unidad que quieres probar, luego seleccionar qué simular es fácil: en una prueba de unidad pura, todo, excepto la "unidad en prueba" debe ser burlado. La razón detrás de esto es que puede estar seguro de sus expectativas de configuració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 utilizan como controles de seguridad para ver si el diseño del software es correcto, debe tener en cuenta que serán frágiles y no siempre dará ningún indicador sobre qué es exactamente lo que está mal en su aplicación o sistema.

    
respondido por el Spoike 10.11.2011 - 12:08

Lea otras preguntas en las etiquetas