Si su función hace algo interesante más allá de sacar los datos de la base de datos, debe extraer la recuperación en una función diferente y simularla, para que pueda probar el resto.
Esto todavía te deja con la tarea de probar el acceso a la base de datos. Realmente no se puede hacer una prueba unitaria para eso, porque eso por definición no tendría acceso a ningún archivo db y podría probar si envía el enunciado sql que cree que debería, pero no si el enunciado sql realmente funciona.
por lo que necesita una base de datos
Usted tiene varias optiones:
1) crear una base de datos fija para este tipo de pruebas que no puedan ser cambiados por las pruebas.
Pro: Conceptualmente fácil Con: difícil de mantener. Las pruebas se vuelven interdependientes porque dependen de los mismos datos. No hay forma de probar cosas que hagan actualizaciones, insertos o borrados (y mucho menos DDL)
2) crear una base de datos durante la prueba. Ahora tiene dos problemas: configurar la base de datos para la prueba y llenarla con datos.
Configuración:
1) tiene un servidor de base de datos en ejecución, con un usuario/esquema/base de datos para erveryone que necesita para ejecutar las pruebas (al menos desarrolladores + ci-servidor). Schema puede crearse usando cosas como Hibernate o los scripts que usa para la implementación.
Funciona muy bien, pero vuelve locos a los anticuados DBA. La aplicación no debe depender del nombre del esquema. También tendrá problemas cuando tenga más de un esquema utilizado por la aplicación. Esta configuración es bastante lenta. Puede ayudar a poner en discos rápidos. Al igual que los discos RAM
2) Tener una base de datos en la memoria. Fácil de comenzar desde el código y rápido. Pero en la mayoría de los casos se comportará igual que su base de datos de producción. Esto es menos preocupante si usa algo que intenta ocultar la diferencia. A menudo uso una base de datos en memoria para la primera etapa de compilación y otra real en una segunda etapa.
Carga del testdata
1) la gente me dice utilizar DBUnit. No estoy seguro de que parezca que hay muchos XML y es difícil de mantener cuando las columnas o restricciones cambian.
2) Prefiero el código de aplicación normal. (Java + Hibernate) en mi caso, pero el código que escribe sus datos en la base de datos en producción debería ser adecuado en muchos casos para escribir datos de prueba para su prueba. Ayuda tener una pequeña API especial que oculta los detalles de la satisfacción de todas las claves foráneas y cosas: http://blog.schauderhaft.de/2011/03/13/testing-databases-with-junit-and-hibernate-part-1-one-to-rule-them/
Esto podría ser interesante: http://blog.schauderhaft.de/2011/03/13/testing-databases-with-junit-and -hibernate-part-1-one-to-rule-them/ –