Hello everyone! In this blog, we will start with the Basic Introduction of Testcontainers and how Testcontainers help in Integration testing along with its benefits and drawbacks also.
What is Testcontainers?
As per the official documentation, “Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything else that can run in a Docker container.” Basically, Our tests can spin up the containers with the parameters needed.
- Due to its ability to use Docker containers within our tests. We are able to include external dependencies within our tests, such as database layer, stream processing, selenium, AWS mocks (localStack), any Docker image, or any application as defined in Docker compose files.
- The necessary Docker containers will be spun up for the duration of the tests and tear down once the test execution has finished.
How do Testcontainers enhance the Integration Tests?
- Today, software companies rely on pipelines for continuous integration and delivery to build, test, and deploy applications.
- An automation testing strategy with realistic testing environments is essential for a successful build promotion strategy.
- One of the most common methods for setting up a test environment on a continuous integration pipeline is to run docker containers beforehand for the services needed to run the tests.
Now we have a java library, known as Testcontainer which compliments the integration testing well.
Integration Tests
- The purpose of integration tests is to assess how our code will behave when communicating with external services.
- Not only in happy path scenarios but especially in corner cases. For example, an external service will respond with an unexpected HTTP code, the HTTP response will come after a defined timeout, and AWS S3 responses with internal errors.
A common problem when writing integration tests is the dependency on installed components where the integration tests are supposed to run. Think about databases, web browsers, etc. Wouldn’t it be great if we could spin off a database instance in a Docker container when starting our integration test? We would always start with a clean database and our integration tests could run on any machine. This is where Testcontainers is designed for. Testcontainers is a Java library that can be used in JUnit tests.
Benefits
- Software delivery and testing more predictable – This means you can use the same environment (a container) to host your software whether you are building, testing, or deploying software in production.
- What you test is what you get – This means the containerization provides a consistent application environment for software testing and for deployment. You can be sure that the testing will accurately reflect how is the application in production. Because the test and production environments are the same.
- Simpler test branches – Software testers often test multiple versions of an application. They might have to test Windows and Linux versions, for example. The versions need to descend from the same codebase but are tested and deployed separately.
Drawbacks
- Containers are not hardware-agnostic – There are a few disadvantages of using containers to do software testing.
- Testing microservices – It’s very challenging to test microservices with test containers. Because you need to configure automated tests to cover multiple microservices.
Test Dependencies supported-
Conclusion
Conclusively, Testcontainers provides a good option for containerizing external dependencies within our tests. Thus providing a quicker turnaround time for integration tests and hence fastening the feedback loop for java applications. With TestContainers, we no longer need to manage the external dependencies ourselves, while running tests locally or in CI, which is a huge win.
I’m hoping that this introduction to Testcontainers will be useful to you.
Reference
https://www.testcontainers.org
