Techniquement, les tests qui parlent à une base de données (nosql ou autre) ne sont pas des tests unitaires, car les tests testent les interactions avec un système externe, et pas seulement une unité de code isolée. Cependant, les tests qui parlent à une base de données sont souvent extrêmement utiles et sont souvent assez rapides pour être exécutés avec les autres tests unitaires.
Habituellement, j'ai une interface de service (par exemple UserService) qui encapsule toute la logique de traitement de la base de données. Le code qui s'appuie sur UserService peut utiliser une version simulée de UserService et est facilement testé.
Lors du test de l'implémentation du service qui parle à Mongo (par exemple, MongoUserService), il est plus simple d'écrire du code java qui démarrera/arrêtera un processus mongo sur la machine locale, et que votre MongoUserService se connecte à cela, voir cette question pour certains Remarques.
Vous pouvez essayer de vous moquer de la fonctionnalité de la base de données lors du test de MongoUserService, mais cela est généralement trop sujet aux erreurs et ne teste pas ce que vous voulez vraiment tester, à savoir l'interaction avec une base de données réelle. Ainsi, lors de l'écriture de tests pour MongoUserService, vous configurez un état de base de données pour chaque test. Regardez DbUnit pour un exemple de framework permettant de le faire avec une base de données.
