In a previous series of blog posts I explained how to use TestContainers for your Java Junit tests. Some of the issues we did not address were about how to test N1QL, create your own buckets, index etc… This post will be about building Spring Data Couchbase test cases and cover theses questions we left out.

Hardwire Unconfigurable Port

One of the limitations we currently have on Couchbase Server is that you cannot change some of the default port. This is a problem with Docker as it’s changing ports only notified otherwise. This can be great because it means you can have several Couchbase instances running on the same machine. But unfortunately won’t work so some ports will have to be fixed. This can be declared fairly easily with TestContainers using the addFixedExposedPort method.

With that out of the way, our Java SDK will be able to connect to N1QL.

Abstract Spring Data Couchbase Docker Test Case

The goal here is to create an abstract test case that will be used by any class that needs a Couchbase instance and Spring Data Couchbase configured. It starts as in the previous posts by instantiating a CouchbaseContainer field. Since we are testing Spring Data we configure support for Index, Query and let’s throw in FTS for later.

To make sure this class will run tests for your application, add the @RunWith(SpringRunner.class) annotation. And to make sure your application configuration is tested as well as our custom configuration, add @SpringBootTest(classes = {GittalentBackendApplication.class, AbstractSPDataTestConfig.CouchbaseTestConfig.class}).

Now talking about custom configuration, what do we need? We want to override the default Couchbase configuration of the app. To do so we need to implement a CouchbaseConfigurer. This interface defines all the bean needed for Spring Data Couchbase to work properly. It provides instances for CouchbaseEnvironment, ClusterInfo, Cluster and Bucket.

They will all come from our CouchbaseContainer setup before running the tests. So we need to make sure that the Container is running and ready before intializing all the beans. This can be achieve by adding an init() method annotated with @PostConstruct. This will allow us to first make sure the container is running, then setup additional stuff. In the following example we setup a bucket called default and setup the Index type to be MOI.

Once we have this abstract test case, all we have to do next is create a class that extends it and start writing tests! Here we can inject Services from our application as well as a lower level Bucket. What you see in this test is first a call to an importer service that create documents. Then we create an Index on the default bucket and test a query on it.

As you can see once the Abstract test case is created, the amount of code is really minimal and correspond exactly to what you want to test.


Posted by Laurent Doguin, Developer Advocate, Couchbase

Laurent is a Paris based Developer Advocate where he focuses on helping Java developers and the French community. He writes code in Java and blog posts in Markdown. Prior to joining Couchbase he was Nuxeo’s community liaison where he devoted his time and expertise to helping the entire Nuxeo Community become more active and efficient.


  1. […] Couchbase developer advocate Laurent Doguin put together a nice look at testing Spring Data Couchbase applications with Test Containers and Spring […]

  2. dreaser dreaser August 25, 2018 at 8:34 pm


    I’m having issues when doing multiple files extending the Abstract class.

    Can you try on your side ? See if there is something I’m doing wrong…

    Thanks in advance,


Leave a reply