For good application architecture, your main application logic should communicate with the Repository, which does not expose any details about the underlying data store. Ideally, the classes that go in/out shouldn’t depend on anything specific to the database (for example, don’t use JDBC-annotated classes in your Repository interface). The repository’s implementation is then responsible for communicating to the database, handling errors, and formatting responses to the common models used by the rest of the application.
For testing these components, anything that depends on the Repository shouldn’t need Mongo running to complete the test. Use a fake Repository implementation here. This should be the majority of your application’s tests.
However, the Repository itself should also be tested, which does need a Mongo instance running to validate it correctly. Don’t try to use a mocking framework to mock the ORM’s APIs or create some kind of fake, because you need to validate the actual connection and behavior of your Mongo queries. This would be more like an integration test, and you shouldn’t need very many of them.