Técnicamente, las pruebas que se comunican con una base de datos (nosql o de otro tipo) no son pruebas unitarias, ya que las pruebas prueban interacciones con un sistema externo y no solo prueban una unidad de código aislada. Sin embargo, las pruebas que se comunican con una base de datos suelen ser extremadamente útiles y suelen ser lo suficientemente rápidas como para ejecutarse con otras pruebas unitarias.
Por lo general, tengo una interfaz de servicio (por ejemplo, UserService) que encapsula toda la lógica para tratar con la base de datos. El código que se basa en UserService puede usar una versión simulada de UserService y se prueba fácilmente.
Al probar la implementación del Servicio que habla con Mongo (por ejemplo, MongoUserService), es más fácil escribir un código Java que iniciará/detendrá un proceso mongo en la máquina local, y hacer que su MongoUserService se conecte a eso, vea esta pregunta para algunos notas
Podría intentar simular la funcionalidad de la base de datos mientras prueba MongoUserService, pero generalmente eso es demasiado propenso a errores y no prueba lo que realmente quiere probar, que es la interacción con una base de datos real. Entonces, al escribir pruebas para MongoUserService, configura un estado de base de datos para cada prueba. Mire DbUnit para ver un ejemplo de un marco para hacerlo con una base de datos.
