An Efficient Object Storage for JUnit Tests

DZone 's Guide to

An Efficient Object Storage for JUnit Tests

There are several limitations to store and fetch such data —to resolve the problem it was suggested to find more suitable data storage.

· Performance Zone ·
Free Resource

One day I faced the problem with downloading a relatively large binary data file from PostgreSQL. There are several limitations to store and fetch such data (all restrictions could be found in official documentation). To resolve the problem it was suggested to find more suitable data storage.

For some internal reasons well known Amazon S3 bucket was chosen for this purpose. The choice affected the project's unit test base. It's still not possible to continue using light-weighted databases such as HSQL or H2 to implement tests. It is a key problem which we will try to resolve in this article.

You may also like: Integrating With File Storage vs. Object Storage

Object Storage Construction

One possible solution to keep unit tests alive is to implement some mock object storage, fully compatible with S3 bucket client, on the other hand, we could use already existing object storage of this type. MinIO is a great example of pretty simple, but high-performance object storage, which is at the same time compatible with Amazon S3 (at least it is written in the documentation).

To integrate MinIO to our unit test we will use a powerful Testcontainers library written in Java. Testcontainers is a special library that supports JUnit tests and provides lightweight, throwaway instances of common databases, Selenium web browsers and anything else that can run in a Docker container. To start using this amazing library it is just necessary to have Docker and add the following dependency to our pom.xml:


Unfortunately, there is no appropriate container for our goal, but the library provides all the necessary tools to create it easily by yourself. Luckily, there is an official docker image for MinIO on DockerHub.

To create an own MinIO container it is necessary to extend GenericContainer with custom data: DEFAULT_PORT (MonIO documentation suggests using 9000 port), DEFAULT_IMAGE (image name), DEFAULT_TAG (image version).

Be attentive with tag assigning! In our example, it is used "edge" tag to support the last deployed MinIO version, but at most times it is better to fix tag and update it manually from time to time to avoid unpredictable test crashes. It is also highly recommended to provide credentials (access key, secret key) to control access to the container. Here is an example of the implementation of a custom MinIO container:



Since we have a proper test container that could be used as a provider of Amazon S3 bucket object storage it is time to show an example of a simple JUnit test with it. Of course, firstly we need to configure S3 client for interacting with our container. In our case, we use the original AmazonS3Client. Therefore, to implement our unit test we need to add an extra dependence.


Here is an ordinary test for creating an S3 bucket with the specified name:


Example code from this post can be found over on GitHub.

Further Reading

Deploying Big Data Workloads on Object Storage Without Performance Penalty

Object Store Connector in Mule ESB

Working With Object Store in Mule, Part 1

java ,docker ,testcontainers ,amazon s3 ,test ,minio ,performance

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}