NoSQLUnit 0.3.0: Released and Passing the Test

显示全部楼层 · 2007-1-24 12:56:49

Introduction
Unit testing is a method by which the smallest testable part of an application is validated. Unit tests must follow the FIRST Rules; these are Fast, Isolated, Repeatable, Self-Validated and Timely.
It is strange to think about a JEE application without persistence layer (typical Relational databases or new NoSQL databases) so should be interesting to write unit tests of persistence layer too. When we are writing unit tests of persistence layer we should focus on to not break two main concepts of FIRST rules, the fast and the isolated ones.
Our tests will be fast if they don't access network nor filesystem, and in case of persistence systems network and filesystem are the most used resources. In case ofRDBMS ( SQL ), many Java in-memory databases exist like Apache Derby , H2 orHSQLDB . These databases, as their name suggests are embedded into your program and data are stored in memory, so your tests are still fast. The problem is withNoSQL systems, because of their heterogeneity. Some systems work using Document approach (like MongoDb ), other ones Column (like Hbase ), or Graph (like Neo4J ). For this reason the in-memory mode should be provided by the vendor, there is no a generic solution.
Our tests must be isolated from themselves. It is not acceptable that one test method modifies the result of another test method. In case of persistence tests this scenario occurs when previous test method insert an entry to database and next test method execution finds the change. So before execution of each test, database should be found in a known state. Note that if your test found database in a known state, test will be repeatable, if test assertion depends on previous test execution, each execution will be unique. For homogeneous systems like RDBMS , DBUnit exists to maintain database in a known state before each execution. But there is no like DBUnitframework for heterogeneous NoSQL systems.
NoSQLUnit resolves this problem by providing a JUnit extension which helps us to manage lifecycle of NoSQL systems and also take care of maintaining databases into known state.

千问 · 2007-1-24 12:56:49

NoSQLUnit
NoSQLUnit is a JUnit extension to make writing unit and integration tests of systems that use NoSQL backend easier and is composed by two sets of Rules and a group of annotations.
First set of Rules are those responsible of managing database lifecycle; there are two for each supported backend.

The first one (in case it is possible) it is the in-memory mode. This mode takes care of starting and stopping database system in "in-memory" mode. This mode will be typically used during unit testing execution.

The second one is the managed mode. This mode is in charge of startingNoSQL server but as remote process (in local machine) and stopping it. This will typically used during integration testing execution.

Second set of Rules are those responsible of maintaining database into known state. Each supported backend will have its own, and can be understood as a connection to defined database which will be used to execute the required operations for maintaining the stability of the system.
Note that because NoSQL databases are heterogeneous, each system will require its own implementation.
And finally two annotations are provided, @UsingDataSet and @ShouldMatchDataSet , (thank you so much Arquillian people for the name) to specify locations of datasets and expected datasets.

千问 · 2007-1-24 12:56:49

MongoDb Example
Now I am going to explain a very simple example of how to use NoSQLUnit, for full explanation of all features provided, please read documentation in link or download in pdf format.
To use NoSQLUnit with MongoDb you only need to add next dependency:

com.lordofthejars

nosqlunit-mongodb

0.3.0
view rawpom.xmlThis Gist brought to you by GitHub.
First step is defining which lifecycle management strategy is required for your tests. Depending on kind of test you are implementing (unit test, integration test, deployment test, ...) you will require an in-memory approach, managed approach or remote approach.
For this example we are going to use managed approach using ManagedMongoDb Rule) but note that in-memory MongoDb management is also supported (see documentation how).
Next step is configuring Mongodb rule in charge of maintaining MongoDb database into known state by inserting and deleting defined datasets. You must register MongoDbRule JUnit rule class, which requires a configuration parameter with information like host, port or database name.
To make developer's life easier and code more readable, a fluent interface can be used to create these configuration objects.
Let's see the code:
First thing is a simple POJO class that will be used as model class:
public class Book {

private String title;

private int numberOfPages;

public Book(String title, int numberOfPages) {

super();

this.title = title;

this.numberOfPages = numberOfPages;

}

public void setTitle(String title) {

this.title = title;

}

public void setNumberOfPages(int numberOfPages) {

this.numberOfPages = numberOfPages;

}

public String getTitle() {

return title;

}

public int getNumberOfPages() {

return numberOfPages;

}
}
view rawBook.javaThis Gist brought to you by GitHub.
Next business class is the responsible of managing access to MongoDb server:
public class BookManager {

private static final Logger LOGGER = LoggerFactory.getLogger(BookManager.class);

private static final MongoDbBookConverter MONGO_DB_BOOK_CONVERTER = new
MongoDbBookConverter();

private static final DbObjectBookConverter DB_OBJECT_BOOK_CONVERTER = new DbObjectBookConverter();

private DBCollection booksCollection;

public BookManager(DBCollection booksCollection) {

this.booksCollection = booksCollection;

}

public void create(Book book) {

DBObject dbObject = MONGO_DB_BOOK_CONVERTER.convert(book);

booksCollection.insert(dbObject);

}
}
view rawBookManager.javaThis Gist brought to you by GitHub.
And now it is time for testing. In next test we are going to validate that a book is inserted correctly into database.
package com.lordofthejars.nosqlunit.demo.mongodb;
public class WhenANewBookIsCreated {

@ClassRule

public static ManagedMongoDb managedMongoDb = newManagedMongoDbRule().mongodPath("/opt/mongo").build();

@Rule

public MongoDbRule remoteMongoDbRule = new MongoDbRule(mongoDb().databaseName("test").build());

@Test

@UsingDataSet(locations="initialData.json", loadStrategy=LoadStrategyEnum.CLEAN_INSERT)

@ShouldMatchDataSet(location="expectedData.json")

public void book_should_be_inserted_into_repository() {

BookManager bookManager = new BookManager(MongoDbUtil.getCollection(Book.class.getSimpleName()));

Book book = new Book("The Lord Of The Rings", 1299);

bookManager.create(book);

}
}
view rawWhenANewBookIsCreated.javaThis Gist brought to you by GitHub.

千问 · 2007-1-24 12:56:49

See that first of all we are creating using ClassRule annotation a managed connection to MongoDb server. In this case we are configuring MongoDb path programmatically, but also can be set from MONGO_HOME environment variable. See here full description of all available parameters.
This Rule will be executed when test is loaded and will start a MongoDb instance. Also will shutdown the server when all tests have been executed.
Next Rule is executed before any test method, and is responsible of maintaining database into known state. Note that we are only configuring working database, in this case the test one.
And finally we annotate method test with @UsingDataSet indicating where to find data to be inserted before execution of each test, and @ShouldMatchDataSet locating expected dataset.
{

"Book":

[

{"title":"The Hobbit","numberOfPages":293}

]
}
view rawinitialData.jsonThis Gist brought to you by GitHub.

{

"Book":

[

{"title":"The Hobbit","numberOfPages":293},

{"title":"The Lord Of The Rings","numberOfPages":1299}

]
}
view rawexpectedData.jsonThis Gist brought to you by GitHub.
We are setting an initial dataset in file initialData.json located at classpath com/lordofthejars/nosqlunit/demo/mongodb/initialData.json and expected dataset called expectedData.json.

Final Notes
Although NoSQLUnit is at early stages, the part of MongoDb is almost finished, in next releases new features and of course new databases will be supported. Next NoSQL supported engines will be Neo4J, Cassandra, HBase and CouchDb.
Also read the documentation where you will find an full explanation of each feature explained here.
And finally any suggestion you have, any recommendation, or any advice will be welcomed.

千问 · 2007-1-24 12:56:49

Unit testing is a method by which the smallest testable part of an application is validated. Unit tests must follow the FIRST Rules; these are Fast, Isolated, Repeatable, Self-Validated and Timely.
It is strange to think about a JEE application without persistence layer (typical Relational databases or new NoSQL databases) so should be interesting to write unit tests of persistence layer too. When we are writing unit tests of persistence layer we should focus on to not break two main concepts of FIRST rules, the fast and the isolated ones.
Our tests will be fast if they don't access network nor filesystem, and in case of persistence systems network and filesystem are the most used resources. In case ofRDBMS ( SQL ), many Java in-memory databases exist like Apache Derby , H2 orHSQLDB . These databases, as their name suggests are embedded into your program and data are stored in memory, so your tests are still fast. The problem is withNoSQL systems, because of their heterogeneity. Some systems work using Document approach (like MongoDb ), other ones Column (like Hbase ), or Graph (like Neo4J ). For this reason the in-memory mode should be provided by the vendor, there is no a generic solution.
Our tests must be isolated from themselves. It is not acceptable that one test method modifies the result of another test method. In case of persistence tests this scenario occurs when previous test method insert an entry to database and next test method execution finds the change. So before execution of each test, database should be found in a known state. Note that if your test found database in a known state, test will be repeatable, if test assertion depends on previous test execution, each execution will be unique. For homogeneous systems like RDBMS , DBUnit exists to maintain database in a known state before each execution. But there is no like DBUnitframework for heterogeneous NoSQL systems.
NoSQLUnit resolves this problem by providing a JUnit extension which helps us to manage lifecycle of NoSQL systems and also take care of maintaining databases into known state.