La mia domanda è una variazione di questa .

Poiché il mio progetto di app Web Java richiede molti filtri / query di lettura e interfacce con strumenti come GridFS, sto lottando per pensare a un modo sensato per utilizzare MongoDB nel modo suggerito dalla soluzione sopra.

Pertanto, sto considerando di eseguire un'istanza incorporata di MongoDB insieme ai miei test di integrazione. Mi piacerebbe che si avviasse automaticamente (sia per ogni test che per l'intera suite), svuota il database per ogni test e si spenga alla fine. Questi test potrebbero essere eseguiti su macchine di sviluppo oltre che sul server CI, quindi anche la mia soluzione dovrà essere portabile .

Qualcuno con maggiori conoscenze su MongoDB può aiutarmi a farmi un'idea della fattibilità di questo approccio e / o forse suggerire qualsiasi materiale di lettura che possa aiutarmi a iniziare?

Sono anche aperto ad altri suggerimenti che le persone potrebbero avere su come affrontare questo problema ...

Ecco una versione aggiornata (per il 2019) della risposta accettata da @rozky (molto è stato cambiato sia nelle librerie Mongo che in quelle 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());
    }

}

Ho trovato la libreria MongoDB incorporata che sembra piuttosto promettente e fa quello che hai chiesto.

Attualmente supporta le versioni di MongoDB: 1.6.5a 3.1.6, a condizione che i binari siano ancora disponibili dal mirror configurato.

Ecco un breve esempio di utilizzo, che ho appena provato e funziona perfettamente:

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));
    }
}

C'è il prodotto Foursquare Fongo . Fongo è un'implementazione java in memoria di mongo. Intercetta le chiamate al driver mongo-java standard per trovare, aggiornare, inserire, rimuovere e altri metodi. L'uso principale è per test unitari leggeri in cui non si desidera avviare un processo mongo.

Se stai usando Maven potresti essere interessato a un plugin che ho creato che racchiude l'API 'embedded mongo' flapdoodle.de :

embedmongo-maven-plugin

Fornisce un startobiettivo che puoi utilizzare per avviare qualsiasi versione di MongoDB che desideri (ad esempio durante pre-integration-test) e un stopobiettivo che interromperà MongoDB (ad esempio durante post-integration-test).

Il vero vantaggio dell'utilizzo di questo plug-in rispetto ad altri è che non è necessario installare in anticipo MongoDB. I binari di MongoDB vengono scaricati e archiviati ~/.embedmongoper build future.

Se stai usando sbt e specs2, ho scritto lo stesso tipo di wrapper per embedmongo

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

con lo spring-boot 1.3 puoi usare 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{
}

È possibile eseguire MongoDB in memoria a partire dalla versione 3.2.6. Dal sito :

A partire da MongoDB Enterprise versione 3.2.6, il motore di archiviazione in memoria fa parte della disponibilità generale (GA) nelle build a 64 bit. Oltre ad alcuni metadati e dati diagnostici, il motore di archiviazione in memoria non conserva alcun dato su disco, inclusi dati di configurazione, indici, credenziali utente, ecc.

Non solo per i test di unità, ma ha anche spiegato come utilizzare inmemory mongodb con rest api.

dipendenza da 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

l'interfaccia pubblica UserRepository estende MongoRepository {

}

per riferimento e tutto il codice java usa il link sottostante: (spiegazione passo passo)

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

Le prestazioni sono migliori quando si esegue mongodconstorageEngine='ephemeralForTest'

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

In produzione, utilizzerai un database reale.

Se vuoi che i tuoi test riflettano il comportamento del tuo prodotto in produzione, usa un'istanza reale di Mongo.

Un'implementazione falsa potrebbe non comportarsi esattamente come una vera. Durante il test, dovresti cercare di essere corretto. La velocità di esecuzione è seconda.