nosql-unit | NoSQL Unit is a JUnit extension | Database library

To use NoSQLUnit with MongoDb you only need to add next dependency:. ~~ {.xml} <dependency> <groupId>com.lordofthejars</groupId> <artifactId>nosqlunit-mongodb</artifactId> <version>${version.nosqlunit}</version> </dependency> ~~. Note that if you are plannig to use in-memory approach it is implemented using Fongo . Fongo is a new project that help with unit testing Java-based MongoDb Applications. [Fongo](https://github.com/fakemongo/fongo).
In NoSQLUnit we can define a replica set architecture and starting it up, so our tests are executed against a replica set servers instead of a single server. Due the nature of replica set system, we can only create a replica set of managed servers. So let’s see how to define an architecture and starting all related servers. The main class is ReplicaSetManagedMongoDb which manages lifecycle of all servers involved in replica set. To build a ReplicaSetManagedMongoDb class, ReplicaSetBuilder builder class is provided and it will allow us to define the replica set architecture. Using it we can set the eligible servers (those that can be primary or secondary), the only secondary servers, the arbiters, the hidden ones, and configure all of them with the attributes like priority, voters, or setting tags. So let’s see an example where we are defining two eligible servers and one arbiter in a replica set called rs-test. ~~ {.java} import static com.lordofthejars.nosqlunit.mongodb.replicaset.ReplicaSetBuilder.replicaSet;. @ClassRule public static ReplicaSetManagedMongoDb replicaSetManagedMongoDb = replicaSet( "rs-test") .eligible( newManagedMongoDbLifecycle().port(27017) .dbRelativePath("rs-0").logRelativePath("log-0") .get()) .eligible( newManagedMongoDbLifecycle().port(27018) .dbRelativePath("rs-1").logRelativePath("log-1") .get()) .arbiter( newManagedMongoDbLifecycle().port(27019) .dbRelativePath("rs-2").logRelativePath("log-2") .get()) .get(); ~~. Notice that you must define different port for each server and also a different database path. Also note that ReplicaSetManagedMongoDb won’t let start executing tests until all replica set becomes stable (this can take some minutes). Then we only have to create a MongoDbRule as usually which will populate defined data into replica set servers. For this case a new configuration builder is provided that allows us to define the mongo servers location and the write concern used during seeding phase. By default Aknownledge write concern is used. ~~ {.java} import static com.lordofthejars.nosqlunit.mongodb.ReplicationMongoDbConfigurationBuilder.replicationMongoDbConfiguration;. @Rule public MongoDbRule mongoDbRule = newMongoDbRule().configure( replicationMongoDbConfiguration().databaseName("test") .seed("localhost", 27017) .seed("localhost", 27018) .configure()) .build(); ~~. Now we have configured and deployed a replica set and populated them with the dataset. But NoSQLUnit also provides an utility method to cause server failures. It is as easy as calling shutdownServer method. ~~ {.java} replicaSetManagedMongoDb.shutdownServer(27017); ~~.
Because @ClassRule is used, we are responsible for restarting the system by calling startServer.
System may become unstable and Mongo driver can throw many exceptions (that’s normal because of MonitorThread) and even do some test fails. If you want to wait until all servers become stable again (in real life you won’t have this possibility), you can use next call:
In NoSQLUnit we can define a sharding architecture and starting it up, so our tests are executed against it instead of a single server. Due the nature of sharding system, we can only create sharding for managed servers. So let’s see how to define an architecture and starting all related servers. The main class is ShardedManagedMongoDb which manages lifecycle of all servers involved in sharding (shards, configs and mongos). To build a ShardedManagedMongoDb class, ShardedGroupBuilder builder class is provided and it will allow us to define each server involved in sharding. Let’s see an example on how to set up and start a system with two shards, one config server and one mongos. ~~ {.java} @ClassRule public static ShardedManagedMongoDb shardedManagedMongoDb = shardedGroup() .shard(newManagedMongoDbLifecycle().port(27018).dbRelativePath("rs-1").logRelativePath("log-1").get()) .shard(newManagedMongoDbLifecycle().port(27019).dbRelativePath("rs-2").logRelativePath("log-2").get()) .config(newManagedMongoDbLifecycle().port(27020).dbRelativePath("rs-3").logRelativePath("log-3").get()) .mongos(newManagedMongosLifecycle().configServer(27020).get()) .get(); ~~. Notice that you must define different port for each server and also a different database path. Also note that in case of mongos you must set the config server port, and is not necessary to set up the database path. And finally we only have to create a MongoDbRule as usually which will populate defined data into sharding servers. For this case we must use the same builder used for replica set but enabling sharding. Keep in mind that in this case we only have to register the mongos instances, not shards or config servers. ~~ {.java} @Rule public MongoDbRule mongoDbRule = newMongoDbRule().configure( replicationMongoDbConfiguration().databaseName("test") .enableSharding() .seed("localhost", 27017) .configure()) .build(); ~~.
In NoSQLUnit we can define a replicated sharded cluster architecture and starting it up, so our tests are executed against it instead of a single server. Due the nature of replicated sharded cluster, we can only create sharding for managed servers. So let’s see how to define an architecture and starting all related servers. The main class is ShardedManagedMongoDb which manages lifecycle of all servers involved in sharding (shards, configs and mongos). To build a ShardedManagedMongoDb class, ShardedGroupBuilder builder class is provided and it will allow us to define each server involved in sharding, but in contrast of sharding, we need to add a replica set instead of a shard. For this reason ReplicaSetManagedMongoDb is also used. Let’s see an example on how to set up two replicated sharded cluster, with one member each replica set, (of course in production environment you would have more), one config server and one mongos. ~~ {.java} import static com.lordofthejars.nosqlunit.mongodb.shard.ShardedGroupBuilder.shardedGroup; import static com.lordofthejars.nosqlunit.mongodb.replicaset.ReplicaSetBuilder.replicaSet;. @ClassRule public static ShardedManagedMongoDb shardedManagedMongoDb = shardedGroup() .replicaSet(replicaSet("rs-test-1") .eligible( newManagedMongoDbLifecycle() .port(27007).dbRelativePath("rs-0").logRelativePath("log-0") .get() ) .get()) .replicaSet(replicaSet("rs-test-2") .eligible( newManagedMongoDbLifecycle() .port(27009).dbRelativePath("rs-0").logRelativePath("log-0") .get() ) .get()) .config(newManagedMongoDbLifecycle().port(27020).dbRelativePath("rs-3").logRelativePath("log-3").get()) .mongos(newManagedMongosLifecycle().configServer(27020).get()) .get(); ~~. Note that we are using the replicaSet method of shardedGroup to create a replica set inside a sharded, and then we use methods defined into ReplicaSetBuilder to configure the replica set. And finally we only have to create a MongoDbRule as usually which will populate defined data into servers. For replicated sharded clusters we can use the same class and dataset as sharding. ~~ {.java} @Rule public MongoDbRule mongoDbRule = newMongoDbRule().configure( replicationMongoDbConfiguration().databaseName("test") .enableSharding() .seed("localhost", 27017) .configure()) .build(); ~~. ~~ {.json} { "collection_name": { "shard-key-pattern": ["attribute_1", "attribute_2"], "data": [ {"attribute_1":"value_1","attribute_2":value_2, "attribute_3":"value_3"} ] } } ~~.
To use NoSQLUnit with Neo4j you only need to add next dependency:. ~~ {.xml} <dependency> <groupId>com.lordofthejars</groupId> <artifactId>nosqlunit-neo4j</artifactId> <version>${version.nosqlunit}</version> </dependency> ~~.
To use NoSQLUnit with Cassandra you only need to add next dependency:. ~~ {.xml} <dependency> <groupId>com.lordofthejars</groupId> <artifactId>nosqlunit-cassandra</artifactId> <version>${version.nosqlunit}</version> </dependency> ~~.
To use NoSQLUnit with Redis you only need to add next dependency:. ~~ {.xml} <dependency> <groupId>com.lordofthejars</groupId> <artifactId>nosqlunit-redis</artifactId> <version>${version.nosqlunit}</version> </dependency> ~~.
To use NoSQLUnit with HBase you only need to add next dependency:. ~~ {.xml} <dependency> <groupId>com.lordofthejars</groupId> <artifactId>nosqlunit-hbase</artifactId> <version>${version.nosqlunit}</version> </dependency> ~~.
To use NoSQLUnit with CouchDB you only need to add next dependency:. ~~ {.xml} <dependency> <groupId>com.lordofthejars</groupId> <artifactId>nosqlunit-couchdb</artifactId> <version>${version.nosqlunit}</version> </dependency> ~~.