Mi pregunta es una variación de esta .

Dado que mi proyecto de aplicación web Java requiere muchos filtros de lectura / consultas e interfaces con herramientas como GridFS, estoy luchando por pensar en una forma sensata de emplear MongoDB de la manera que sugiere la solución anterior.

Por lo tanto, estoy considerando ejecutar una instancia incrustada de MongoDB junto con mis pruebas de integración. Me gustaría que se inicie automáticamente (ya sea para cada prueba o para toda la suite), vacíe la base de datos para cada prueba y se apague al final. Estas pruebas pueden ejecutarse en máquinas de desarrollo, así como en el servidor CI, por lo que mi solución también deberá ser portátil .

¿Alguien con más conocimiento sobre MongoDB puede ayudarme a tener una idea de la viabilidad de este enfoque y / o tal vez sugerir algún material de lectura que pueda ayudarme a comenzar?

También estoy abierto a otras sugerencias que la gente pueda tener sobre cómo podría abordar este problema ...

Aquí hay una versión actualizada (para 2019) de la respuesta aceptada de @rozky (se ha cambiado mucho en las bibliotecas Mongo y Embedded MongoDB).

package com.example.mongo;

import com.mongodb.BasicDBObject;
import com.mongodb.MongoClient;
import com.mongodb.client.MongoCollection;
import com.mongodb.client.MongoDatabase;
import de.flapdoodle.embed.mongo.MongodExecutable;
import de.flapdoodle.embed.mongo.MongodProcess;
import de.flapdoodle.embed.mongo.MongodStarter;
import de.flapdoodle.embed.mongo.config.IMongodConfig;
import de.flapdoodle.embed.mongo.config.MongodConfigBuilder;
import de.flapdoodle.embed.mongo.config.Net;
import de.flapdoodle.embed.mongo.distribution.Version;
import de.flapdoodle.embed.process.runtime.Network;
import java.util.Date;
import org.junit.After;
import static org.junit.Assert.*;
import org.junit.Before;
import org.junit.Test;

public class EmbeddedMongoTest
{
    private static final String DATABASE_NAME = "embedded";

    private MongodExecutable mongodExe;
    private MongodProcess mongod;
    private MongoClient mongo;

    @Before
    public void beforeEach() throws Exception {
        MongodStarter starter = MongodStarter.getDefaultInstance();
        String bindIp = "localhost";
        int port = 12345;
        IMongodConfig mongodConfig = new MongodConfigBuilder()
        .version(Version.Main.PRODUCTION)
        .net(new Net(bindIp, port, Network.localhostIsIPv6()))
        .build();
        this.mongodExe = starter.prepare(mongodConfig);
        this.mongod = mongodExe.start();
        this.mongo = new MongoClient(bindIp, port);
    }

    @After
    public void afterEach() throws Exception {
        if (this.mongod != null) {
            this.mongod.stop();
            this.mongodExe.stop();
        }
    }

    @Test
    public void shouldCreateNewObjectInEmbeddedMongoDb() {
        // given
        MongoDatabase db = mongo.getDatabase(DATABASE_NAME);
        db.createCollection("testCollection");
        MongoCollection<BasicDBObject> col = db.getCollection("testCollection", BasicDBObject.class);

        // when
        col.insertOne(new BasicDBObject("testDoc", new Date()));

        // then
        assertEquals(1L, col.countDocuments());
    }

}

Encontré la biblioteca Embedded MongoDB que parece bastante prometedora y hace lo que ha pedido.

Actualmente es compatible con las versiones de MongoDB: 1.6.5a 3.1.6, siempre que los binarios todavía estén disponibles en el espejo configurado.

Aquí hay un breve ejemplo de uso, que acabo de probar y funciona perfectamente:

public class EmbeddedMongoTest {
    private static final String DATABASE_NAME = "embedded";

    private MongodExecutable mongodExe;
    private MongodProcess mongod;
    private Mongo mongo;

    @Before
    public void beforeEach() throws Exception {
        MongoDBRuntime runtime = MongoDBRuntime.getDefaultInstance();
        mongodExe = runtime.prepare(new MongodConfig(Version.V2_3_0, 12345, Network.localhostIsIPv6()));
        mongod = mongodExe.start();
        mongo = new Mongo("localhost", 12345);
    }

    @After
    public void afterEach() throws Exception {
        if (this.mongod != null) {
            this.mongod.stop();
            this.mongodExe.stop();
        }
    }

    @Test
    public void shouldCreateNewObjectInEmbeddedMongoDb() {
        // given
        DB db = mongo.getDB(DATABASE_NAME);
        DBCollection col = db.createCollection("testCollection", new BasicDBObject());

        // when
        col.save(new BasicDBObject("testDoc", new Date()));

        // then
        assertThat(col.getCount(), Matchers.is(1L));
    }
}

Hay un producto de Foursquare Fongo . Fongo es una implementación java en memoria de mongo. Intercepta llamadas al controlador estándar mongo-java para buscar, actualizar, insertar, eliminar y otros métodos. El uso principal es para pruebas unitarias ligeras en las que no desea iniciar un proceso mongo.

Si está utilizando Maven, puede estar interesado en un complemento que he creado que envuelve la API flapdoodle.de 'embedded mongo' :

embedmongo-maven-plugin

Proporciona un startobjetivo que puede utilizar para iniciar cualquier versión de MongoDB que desee (por ejemplo, durante pre-integration-test) y un stopobjetivo que detendrá MongoDB (por ejemplo, durante post-integration-test).

El beneficio real de usar este complemento sobre otros es que no es necesario instalar MongoDB de antemano. Los binarios de MongoDB se descargan y almacenan ~/.embedmongopara futuras compilaciones.

Si está utilizando sbt y specs2, escribí el mismo tipo de contenedor para embedmongo

https://github.com/athieriot/specs2-embedmongo

con spring-boot 1.3 puede usar EmbeddedMongoAutoConfiguration

pom.xml

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>1.3.2.RELEASE</version>
</parent>
 ...
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-mongodb</artifactId>
    </dependency>
    <dependency>
        <groupId>de.flapdoodle.embed</groupId>
        <artifactId>de.flapdoodle.embed.mongo</artifactId>
        <version>${embedded-mongo.version}</version>
    </dependency>

MongoConfig

@Configuration
@EnableAutoConfiguration(exclude = { EmbeddedMongoAutoConfiguration.class })
public class MongoConfig{
}

Puede ejecutar MongoDB en memoria a partir de la versión 3.2.6. Desde el sitio :

A partir de la versión 3.2.6 de MongoDB Enterprise, el motor de almacenamiento en memoria es parte de la disponibilidad general (GA) en las compilaciones de 64 bits. Aparte de algunos metadatos y datos de diagnóstico, el motor de almacenamiento en memoria no mantiene ningún dato en el disco, incluidos datos de configuración, índices, credenciales de usuario, etc.

No solo para pruebas unitarias, sino que también explicó cómo usar inmemory mongodb con rest api.

dependencia de maven:

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-mongodb</artifactId>
        </dependency>

        <dependency>
            <groupId>de.flapdoodle.embed</groupId>
            <artifactId>de.flapdoodle.embed.mongo</artifactId>
        </dependency>

================================================ ===========================

application.properties

server.port = 8080
spring.data.mongodb.database=user_db
spring.data.mongodb.port=27017
spring.data.mongodb.host=localhost

================================================ ===========================

UserRepository.java

UserRepository de interfaz pública extiende MongoRepository {

}

para referencia y todo el código Java, use el siguiente enlace: (explicación paso a paso)

https://www.youtube.com/watch?v=2Tq2Q7EzhSA&t=7s

Las actuaciones son mejores cuando se ejecuta mongodconstorageEngine='ephemeralForTest'

new MongodConfigBuilder()
    .version(Version.Main.PRODUCTION)
    .cmdOptions(new MongoCmdOptionsBuilder()
         .useStorageEngine("ephemeralForTest")
         .build())
    .net(new Net("localhost", port, Network.localhostIsIPv6()))
    .build()

En producción, utilizará una base de datos real.

Si desea que sus pruebas reflejen cómo se comporta su producto en producción, use una instancia real de Mongo.

Es posible que una implementación falsa no se comporte exactamente igual que una real. Al realizar la prueba, debe esforzarse por lograr la corrección. La velocidad de ejecución ocupa el segundo lugar.