Moje pytanie jest odmianą tego .

Ponieważ mój projekt aplikacji internetowej Java wymaga wielu filtrów / zapytań odczytu i interfejsów z narzędziami takimi jak GridFS, staram się wymyślić rozsądny sposób wykorzystania MongoDB w sposób sugerowany przez powyższe rozwiązanie.

Dlatego rozważam uruchomienie osadzonej instancji MongoDB wraz z moimi testami integracji. Chciałbym, aby uruchamiał się automatycznie (dla każdego testu lub całego zestawu), opróżniał bazę danych dla każdego testu i wyłączał się na końcu. Te testy mogą być uruchamiane na maszynach programistycznych, a także na serwerze CI, więc moje rozwiązanie również musi być przenośne .

Czy ktoś, kto ma większą wiedzę na temat MongoDB, może mi pomóc zorientować się w wykonalności tego podejścia i / lub może zasugerować materiały do ​​czytania, które mogą mi pomóc w rozpoczęciu?

Jestem również otwarty na inne sugestie, które ludzie mogą mieć, jak rozwiązać ten problem ...

Oto zaktualizowana (na rok 2019) wersja zaakceptowanej odpowiedzi od @rozky (wiele się zmieniło w bibliotekach Mongo i 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());
    }

}

Znalazłem wbudowaną bazę danych MongoDB bibliotekę która wygląda całkiem obiecująco i robi to, o co prosiłeś.

Obecnie obsługuje wersje MongoDB: 1.6.5do3.1.6 , pod warunkiem, że pliki binarne są nadal dostępne ze skonfigurowanego serwera lustrzanego.

Oto krótki przykład użycia, który właśnie wypróbowałem i działa idealnie:

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

Jest produkt Foursquare Fongo . Fongo to implementacja mongo w języku Java w pamięci. Przechwytuje wywołania standardowego sterownika mongo-java w celu znalezienia, aktualizacji, wstawienia, usunięcia i innych metod. Głównym zastosowaniem jest lekkie testowanie jednostkowe, w którym nie chcesz przyspieszać procesu mongo.

Jeśli używasz Mavena, możesz być zainteresowany wtyczką, którą stworzyłem, która otacza API 'embedded mongo' flapdoodle.de :

embedmongo-maven-plugin

Zapewnia startcel, którego możesz użyć do uruchomienia dowolnej wersji MongoDB (np. W trakcie pre-integration-test) oraz stopcel, który zatrzyma MongoDB (np. W trakcie post-integration-test).

Prawdziwą zaletą korzystania z tej wtyczki w porównaniu z innymi jest to, że nie ma potrzeby wcześniejszej instalacji MongoDB. Pliki binarne MongoDB są pobierane i przechowywane na ~/.embedmongopotrzeby przyszłych kompilacji.

Jeśli używasz sbt i specs2, napisałem ten sam rodzaj opakowania dla embedmongo

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

dzięki spring-boot 1.3 możesz użyć 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{
}

Możesz uruchomić MongoDB w pamięci od wersji 3.2.6. Ze strony :

Począwszy od MongoDB Enterprise w wersji 3.2.6, aparat magazynowania w pamięci jest częścią ogólnej dostępności (GA) w kompilacjach 64-bitowych. Poza niektórymi metadanymi i danymi diagnostycznymi, silnik przechowywania w pamięci nie przechowuje żadnych danych na dysku, w tym danych konfiguracyjnych, indeksów, poświadczeń użytkownika itp.

Nie tylko do testowania jednostkowego, ale także wyjaśnił, jak używać inmemory mongodb z resztą api.

zależność 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

publiczny interfejs UserRepository rozszerza MongoRepository {

}

w celach informacyjnych, a cały kod java użyj poniższego linku: (wyjaśnienie krok po kroku)

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

Wydajność jest lepsza podczas wykonywania mongodzstorageEngine='ephemeralForTest'

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

W produkcji będziesz korzystać z prawdziwej bazy danych.

Jeśli chcesz, aby Twoje testy odzwierciedlały zachowanie Twojego produktu podczas produkcji, użyj prawdziwej instancji Mongo.

Fałszywa implementacja może nie zachowywać się dokładnie tak samo, jak prawdziwa. Podczas testowania powinieneś dążyć do poprawności. Szybkość wykonania jest na drugim miejscu.