Delightful Integration Tests With Testcontainers
From Author:
Dockerized services are an excellent tool for creating repeatable, isolated environments ideal for integration tests. In this session, we'll look at the Testcontainers libraries which provide flexible and intuitive API for programmatically controlling lifecycle of your service dependencies in Docker containers. Running databases, Kafka, Elasticsearch, and even cloud technologies, straight from your test code ensures environment config is always up-to-date and consistent during local development and in CI pipelines.
You’ll learn everything necessary to start adding powerful integration tests to your codebase without the headache of managing external service dependencies manually!
This talk has been presented at TestJS Summit 2022, check out the latest edition of this JavaScript Conference.
FAQ
TestContainers is a library that integrates with Docker to create ephemeral environments for running third-party service dependencies required by an application, such as databases and message brokers. It is important because it allows for reliable and repeatable integration testing by programmatically managing the lifecycle of these containers, thus ensuring that applications work as expected with real dependencies.
TestContainers enhances integration testing by providing a programmable environment to manage, configure, and clean up Docker containers. This allows developers to test applications under specific scenarios and stress conditions, ensuring robustness and reliability before production deployment. It supports various technologies and simplifies the setup, making it easier to focus on business logic rather than infrastructure management.
Yes, TestContainers is available in libraries for different programming languages, including Java, JavaScript, TypeScript, .NET, Go, Python, and Rust. This versatility makes it a suitable tool for integration testing in diverse development environments and programming ecosystems.
Applications that interact with external services like databases, APIs, message brokers, and cloud technologies benefit most from using TestContainers. This includes backend applications, particularly those structured as microservices, where integration tests can verify the interactions with these third-party systems.
TestContainers automatically handles the cleanup of containers after tests are completed. This includes both successful and failed tests, as well as scenarios where the testing machine or environment encounters issues like crashes. This ensures that no residual data or state interferes with subsequent tests, maintaining a clean and reliable testing environment.
TestContainers is compatible with various Docker environments, including Docker Desktop and other Docker-compatible implementations like Minikube. This flexibility allows it to be used in a range of development and testing scenarios, whether locally or in cloud-based setups.
To integrate TestContainers in a project, one needs to add the appropriate TestContainers library as a dependency in their project configuration. Developers can then utilize the library to define and manage Docker containers programmatically within their test suites, configuring necessary services and ensuring their application interacts correctly with these services during tests.
Video Transcription
1. Introduction to Integration Testing
Testing is super important for development and production. Automated tests are crucial for releasing software. Integration tests have become more popular as applications rely on interactions with third-party systems. They provide a reliable test suite that catches real-world issues.
Hi. You're watching TestJS Summit and this is delightful integration tests with test containers. Testing is very important. More projects should test applications better and I hope after this quick session you're gonna learn about how you can do integration tests which you like using Test Containers libraries.
My name is Alex Shoive and I work as a Developer Relations person at Atomic Jar, a company created... a startup created by the Test Containers Java maintainers originally and now we have more people from different language ecosystems helping us work on Test Containers. If you have any questions, you can find me online. I'd be happy to chat about anything. Test Containers, so testing related or just software engineering in general. I think it would be very, very cool. So drop me, drop me a line.
Testing is super, super important because it lies on the critical paths from development to production. If we don't have the good automated test suite, we cannot release things well. We need to have automated tests because we want to make sure that whenever we have something that we potentially want to release, we can go through our pipeline without bottlenecking on any manual process. This is helpful during a normal development practice, development loop, but it's also super helpful in case there are any security issues or supply chain security issues where you update the third party packages, and then you need to release things because they could be security and vulnerability fixes, but if you don't have good test suits that you trust, then this is a manual process and you are as good as exposed. But if you do, you can run your automated tests. You can release immediately because you have confidence in your tests. This is very, very important, and lately, the way how we see what types of tests we want to run has been shifted.
In the past, we had the testing pyramid and we run a ton of unit tests and they covered all possible scenarios and we had very good test coverage, and then we still missed some issues. So, recently, independent teams have been coming out how they're rethinking the testing pyramid and how they put more and more emphasis on integration tests. Meanwhile, it makes a lot of sense. Our applications have become smaller. We are mostly writing, and we are talking about the backend applications here, we are mostly writing microservices that talk to other APIs or talk to various technologies like databases or message brokers or Cloud technologies, and the application behavior very much is encoded in the interactions with those third party systems rather than the business logic within the particular application, how it transforms the data. So, it does make sense to have fewer implementation detail tests, and use the integration test which run your application with the immediate environment, with all the necessary components for your application to run properly as it would run in production, but in your testing setup. That could be the bulk of our test suite. That could be the test that we trust and rely on. And we still can have end-to-end integrator tests that run in the environment similar to production, where all the systems are spin up at the same time. And when we check the actual workflows, as if that would be a production environment, production data, or similar data, but in a much larger environment. So for a test suite that you run everywhere, on your machine, on your colleague's machine, in your CI, integration tests hit the sweet spot between the simplicity of the setup and also how many issues with the real-world technologies they can catch. That's why they are getting more and more popular.
2. Introduction to Test Containers
Test containers is a library that integrates with Docker to create ephemeral environments for running third-party service dependencies. It allows you to test your application with real dependencies, making your tests more reliable. Test containers uses Docker as the environment to spin up containers. However, Docker is sometimes inflexible for integration tests. This is where TestContainers comes in, providing programmatic access to create and manage containers for testing.
This brings us to test containers. Test containers is libraries in different languages, including the test getters' node implementation that works for JavaScript and TypeScript. They integrate with Docker to create ephemeral environments where you can run the third-party service dependencies that your application requires. You can run the databases, you can run your Kafka, you can run your Elasticsearch, you can learn your local stack, if you work with LWS technologies.
You can run them in Docker containers, and your application has the full control over the lifecycle of those. And your tests have the full control over the configuration of those. So you can test your application with the real dependencies and know that it works as expected.
Test containers has recently been named in the ThoughtWorks Technology Radar. It was put into the Adult category, which means technically that there should be a strong reason. You should really know what you're doing, if you don't want to use test containers. They are allowing, test containers allows you to create a reliable environment with the programmatic creation of those lightweight containers for your dependencies. And it makes your tests more reliable, and it tries to nudge you into doing the right things with your integration tests, and that's why there are more and more projects, which are using test containers in various setups and environments.
Test containers uses Docker as the environment where it spins up those containers that your application wants to run. And this is great because Docker is almost universally available, it runs on all popular operating systems, and its developers understand how Docker works, or how to use Docker from the outside. So this is a great, great option for leveraging a runtime to run those dependencies for your application. However, the stock sort of look and feel user experience of Docker is not sometimes flexible enough for your integration tests.
Docker is great because it has all the software in the world that can be run in Docker. There are registries where you can pull all the technologies that your soul requires. It provides you with the process isolation. It provides you with the ability to configure both the container and the application within the container. They give you the CPU and memory limits. All those good things, but it is a little bit inflexible for the tests specifically because during the tests, we want to put our application into the specific scenarios where something might go wrong. What will happen when the application works with a database and the data schema is incorrect? Or what will happen if my application doesn't have a long latency until it reaches Kafka? Or what happens when my Redis key numbers are close to the integer range and are trying to overflow? All the different scenarios and they all break the setup in some way. This is the notion of tests. This is what tests should do. They put your application under stress and then they want to figure out whether it behaves correctly. So with Docker, once you break the environment, it's very, very hard to recreate the environment. And this is where TestContainers comes in.
TestContainers gives you the programmatic access to create, manage, lifecycle and clean up the containers that you want to run. It gives you API to configure both the container, like expose which ports you want to expose from the container if you're working with it through the network.
Comments