Cassandra is one of the emerging NoSQL technologies in the Big Data world. If you decided to use it in your project, you might have a good reason for it, and it is also important to ensure that it is well tested locally before proceeding further, in your deployment pipeline, into an integration environment.
Using Mockito to mock Cassandra is always a possibility though a bit tricky, and it does not provide the same level of confidence as testing against Cassandra itself.
Thankfully, cassandra-unit project was created and hosted in github (by @jsevellec). This utility is fully oriented to JUnit testing. But sometimes, either because you prefer TestNG, or by company policies, or just because everything is already in TestNG, you have to create your tests in TestNG.
This post provides a simple example on how to test your Cassandra application with TestNG using an embedded Cassandra cluster through cassandra-unit utility.
Let’s say you are using Maven, you will have to include the following dependencies:
For the sake of the example, let’s say you have a table to store persons information with the following information:
Identifier, an alphanumeric unique identifier of that person
Name, the name of the person
Domain Java Entity
Based on the domain description above, we can define our Java entity as below:
Data Access Object
The DAO implementation will perform the bridge between your application’s domain and the database domain. Let’s consider the following simple DAO interface.
And its implementation for accessing Cassandra:
Note that we are here using QueryBuilder, which provides a fluent API to create Cassandra queries.
Now we need to create a unit test for PersonDaoImpl class. We are testing the following:
Fetch all records from a pre-populated person table in the database and verify it has the expected values.
Insert a person into the database and query the database to check if the records were added successfully.
If you read through the cassandra-unit documentation, the way of declaring the Cassandra cluster for use in your test is something like:
TestNG does not have equivalent to the JUnit rules, but it’s easy to emulate if we think on what this is used for. This basically creates the Cassandra embedded cluster while ensuring that the before and after methods are executed before and after the test scenario. So we can emulate it by using an abstract class and providing @BeforeClass and @AfterClass behaviour.
However, before and load of CassandraCQLUnit are protected, so let’s decorate that class a bit first:
Now our AbstractTest class that will hide the cluster setup and some utility methods for validation purposes.
The db_setup.cql will be used for creating the necessary tables and pre-populating data into the embedded Cassandra database. The test that will fetch all persons from the table is counting on having some pre-populated data. Let’s create the db_setup.cql file:
After have this only-once setup, our test may be created, as well as any tests that need a Cassandra embedded cluster.
It’s important to get your application properly tested locally before deploying into any integration environment. Cassandra Unit project provides the ability of creating a local Cassandra cluster that may be injected into your DAOs in order to emulate the real cluster while testing.
Some tweaks were made in order to have a seamless integration with TestNG while removing the boilerplate cluster setup from the test code itself.