Tecnicamente, os testes que falam com um banco de dados (nosql ou outro) não são testes de unidade, pois os testes estão testando interações com um sistema externo, e não apenas testando uma unidade isolada de código. No entanto, os testes que se comunicam com um banco de dados geralmente são extremamente úteis e geralmente são rápidos o suficiente para serem executados com os outros testes de unidade.

Normalmente eu tenho uma interface de serviço (por exemplo UserService) que encapsula toda a lógica para lidar com o banco de dados. O código que depende do UserService pode usar uma versão simulada do UserService e é facilmente testado.

Ao testar a implementação do serviço que fala com o Mongo, (por exemplo, MongoUserService) é mais fácil escrever algum código java que iniciará/parará um processo mongo na máquina local e fazer com que seu MongoUserService se conecte a isso, veja esta pergunta para alguns notas.

Você pode tentar zombar da funcionalidade do banco de dados enquanto testa o MongoUserService, mas geralmente isso é muito propenso a erros e não testa o que você realmente deseja testar, que é a interação com um banco de dados real. Portanto, ao escrever testes para MongoUserService, você configura um estado de banco de dados para cada teste. Veja no DbUnit um exemplo de estrutura para fazer isso com um banco de dados.