Testcontainers: Making Sense of the Software Testing Landscape with Sergei Egorov

Welcome to the Test Guild Automation Podcast where we all get together to learn more about automation and software testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Automation Podcast. Today we'll be talking with Sergey all about test Containers making sense of the software testing landscape. Sergey is a co founder and CEO of Atomic Jar, a company behind Test Containers, a widely adopted integration testing library that shifts left your testing efforts with integration testing, which I think is a really important topic that a lot of developers and testers get wrong. So before Atomic Jaw, Sergey actually worked as an Engineer at Pivotal VMware, Zero Turnaround and many other startups where he advocated for integration testing. He's also a seasoned speaker and participant in some of the biggest conferences around the world included Devox, BE, Xcon Plus, SpringOne, Platform, Java Zone, to name a few and I'm really excited to have him on the show. Like I said, he knows a lot about integration testing and this test gets is a solution I think is going to help a lot of folks listening. You don't want to miss this episode. Check it out. The Test Guild Automation Podcast is sponsored by the fantastic folks at Sauce Labs. Their cloud based test platform helps ensure your favorite mobile apps and websites work flawlessly on every browser, operating system and device. Get a free trial. Visit testguild.com sourcelabs and click on the exclusive sponsor section to try it for free for 14 days. Check it out.

Hey Sergey, welcome to the Guild.

Hey Joe, thanks for having me. I'm really excited to be here and talk about the testing because I think this topic is so underrepresented out there. People talk about infrastructure, people talk about frameworks, their favorite libraries, their flavor of node JS is odd function but nobody's really talking about testing as much as it should be.

Absolutely. And I love how you focus sitting on testing and especially this new it's not a new solution. It's been around for a while, but I just heard Test containers Before we get into though, sorry guys, is there anything I missed in your bio that you want the Guild to know more about?

No, I think you covered it pretty well. So I'm indeed approaching this topic and starting the company as a developer myself. So I'm not business person who decided to earn some money on this fancy idea some other developer told him about, but rather I'm here as a developer. I've been developer myself for my whole life. I've been using Task Containers, a project we created and we start company for myself. I've been advocating it for companies because I knew that it was making developers lives easier and that's what motivated us to start company for it.

Absolutely. I'd like to dive into atomicjaw after we set the stage a little bit more because I think it's interesting what you're doing and I think that the person that invented test containers actually a cto. So I like to get into that story. But before we get into all that at a high level, I think a lot of people actually get integration testing wrong. I work for a large enterprise. It seems like people know what unit testing is, they know what end to end testing is, but it always gets kind of fuzzy when we get into integration testing. So can you just tell a little bit about the different categories of software testing and how integration testing fits into.

But that's indeed the case and unfortunately with integration testing, even though it's my favorite type of testing, this kind of testing that's so loosely defined, and you're absolutely right that sometimes people refer to integration testing, for example, as more like end to end testing where an integration environment is deployed. And there is a lot of confusion in naming. And I'm not a native speaker obviously, so for me it's confusion, even ads, because I had to learn what it means like integration testing. And then when I see native speakers reasoning about the meaning, I understand that, okay, there's actually some confusing in the industry, not only from the language point of view, but I myself prefer to talk about integration testing more in terms of testing individual components of the system. So if unit testing tests your code and pieces of your code such as functions, then integration testing takes it to the next step where we test individual deliverables such as services. For example, and there is an article on Martin Fowler's blog talking about integration testing as a definition of integration testing. There are good mentions, maybe like the idea of narrowing down things and they even mentioned the idea of like narrow integration testing where you only test a single service and you only start infrastructure that is required for the single service to test it. Because imagine you're Netflix and you need to test your, I don't know, movie catalog service. Obviously you don't need to start authentication service, billing service and many other services, just test your movie catalog. You don't need to deploy the whole infrastructure of these hundreds of thousands, I think now is their scale services just to test a single one. What you only need to start, you need to start your movie catalog service, maybe some network stub for authentication so that you can just verify that if Authentication service according to this contract. This is why I also love contract testing, by the way. Like if authentication service returns the correct token for giving a request, then movie catalog service proceeds correctly. That's only one. Like the only thing you need to verify is that your movie service talks correctly to the notification service, but you don't need to test notification service itself. And then you start databases that are required for this particular service movie service. So let's imagine they're using elasticsearch. Most probably not, but let's say they're using elasticsearch for the movie catalog. Then you only need to start elasticsearch and some network stop for the notification service and you're good to go. You don't need the whole infrastructure to be able to test it. And this makes it much easier to run this thing during the development locally.

Nice. So it sounds like one issue a lot of developers run into is they try to start everything at one time. Are there any other issues that comes into play when people are trying to implement integration testing and make them reliable? Because I know a lot of times people say oh, done reliable. Because they probably try to connect to too many services that have nothing to do with what they're trying to test.

I think it's kind of correlates to the previous issue of trying to start too many things at once is to try start things exactly like you do in production. For example, if you deploy to kubernetes, some developers think that they need to deploy their tasks or they need kubernetes to run their tasks. And this is not true. We live in the world of 12 factor applications and as long as you application is conformant to the 12 factor manifesto, then you can deploy it anywhere, you can start it anywhere, and you don't need kubernetes per se to be able to test your spring boot microservice that can be configured with anything such as environment variables or system properties or anything like that. Or maybe you don't even want to deploy your service, but you want to run your frameworks for every testing tools and there are many frameworks out there. I of course come from Java World, meaning that I know more about Spring Boot, Quarkus, Micronaut and others as opposed to let's say some Node Js frameworks. But I will try to talk about some other frameworks just because it doesn't really matter which language you're using. So let's say you're using Node Js, you're using Express, and then you want to debug your service under Test, you don't necessarily need to pack it as Docker image, deploy it to Kubernetes and run it to be able to run the test. You may as well run it on your machine as part of your test. Start from test, be able to debug it, but start your dependencies in some other environment and we can talk about it later. But I see very often, and our tool is based on Docker, for example, but I see very often people coming and asking, hey, we are deploying to Kubernetes, so why don't you support Kubernetes and then tell them why do you need Kubernetes to start, let's say postgres. You're not testing Postgres operator for Kubernetes, you're testing your service that talks to any Postgres started anywhere. And I think with recent additions to the infrastructure tooling, people started to limit themselves to their infrastructure tooling and they started being less abstract about their infrastructure, which isn't the right trend, I would say. Even though there are some nice abstractions.

Out there, that's a great point. I could definitely see people getting tripped up by that for sure. Do you see that with the trend towards more companies using microservices that integration testing is becoming more feasible or easier for developers? Is there extra complexity? I'm just thinking, once again, enterprise companies have these legacy software that made integration testing kind of funky sometimes. Does microservices lend themselves more to integration testing?

Interestingly enough, I would not say that microservices are easier to test. On the other hand, microservices triggered this wave of developers testing their software with integration testing because there was a major leisure transition means to microservices, meaning that there were a lot of rewrites. And when you rewrite something, most probably you would want to write some test to verify that you wrote it correctly. So we used to have monoliths that are actually easier to test. You don't need to think about contract testing between microservices because it's all part of the same thing. You don't need to introduce contract testing here unless you need to perform some external communication to let's say, some payment gateway provider by some other vendor. But let's say your monolith is self contained and then you only start this monolith and some some database, Oracle, MongoDB or whichever database you prefer. And that's all. It's actually much easier to test monoliths as compared to microservices. On the other hand, these monlease they were usually not covered with SaaS and it was a big problem. And then someone said, hey, we're adopting microservices, so let's start rewriting. And I've seen many companies taking this as an opportunity to introduce testing in development, not even in QA environments, but testing in development. Because rewrites were painful. Rewriting, shipping to production and discovering that you have some major issues or major incompatibilities with your previous product is obviously not something anyone wants to see. This is why microservices are harder to test. Yet more people started testing microservices than monoliths. I would say so two waves, one on top of another. But I think it's a great signal because it only proved that even if testing is harder, it is worse than investment. And this microservices migration kind of project.

That this might be a dumb question. I'm not a developer, I'm just thinking when people checking code to CI cd, do developers normally do the integration test before checking in code or is it always part of the CI CD pipeline.

Depending on how good their tooling is? For example, we use test containers. Our goal was always to give developers access to testing as soon as possible or as close to their software development lifecycle as possible. And with test contains local testing as possible. So you can start it in your machine, the only prerequisite is Docker. And then, then you can start some crazy things. Like imagine 10 years ago someone saying that, yeah, I'm a junior developer and I just configured Kafka, DB2 selenium and a number of other dependencies for testing. After a couple of hours coding something, and most probably the reaction would be like, please give him some vacation, because this person is obviously not telling the truth. And today it's possible because it's the same tool, but great abstraction that gives you that. And because of this simplicity, now we can say that testing is accessible, like any developer can do the testing, proper testing. Because I'm big advocate of integration testing. Not saying that unit testing, for example, is not needed or end to end testing, just saying that integration testing is a very important part of testing, par digging and testing pipeline. And if I had to choose, although this would be terrible because I had to choose only one type of testing, I would definitely choose integration testing because at least this is the right balance between maintainability of tests and the coverage, actual coverage, not code coverage, but actual coverage of what you test. And with the right tooling, developers can test during the development and some even follow integration test driven development where you change the code and you run your integration tests. And this is where the definition of integration test is important. If we define integration tests as something that requires a deployment to a massive environment and creating kubernetes clusters, then that's obviously not something you'd be doing during the development. Even though there are some startups that try to help with that. But I don't think it's the right focus. While we narrowed down integration testing and I even had a Twitter thread with someone from testing community where we tried to redefine integration testing as a term and define new term for what we do here, I think we agreed that I O testing is the closest to what we do here. So unit testing tests code and we test code interactions, but we never cross the boundary of IO interactions. We are not sending queries anywhere, we're just running code. While integration testing in the way we define it is where I O starts happening, we now need to send queries to some external resources. And this is why we thought that maybe IO testing is something we should think about as an industry to use to clearly define what we are talking what we are talking here about.

I love it. I guess one conversation I could see testers having is integration testing because you're not using the actual services. It's not a real test using mocks. How reliable can it be? So do you get that kind of pushback or is that just someone that maybe doesn't understand the real intent of integration testing?

Sometimes it is definitely the case, especially with cloud providers where cannot. So let's say, let's consider Snowflake db. That's a great database. But as long as I'm concerned, they do not provide Snowflake DB emulator that can run locally in Docker container. And let's say in test containers. What we do here, we let developers run anything that can run in Docker container. But that will always be a limitation. Although quite wide range of options. But there will always be some services that are impossible to to test locally. And we're happy to see cloud providers investing more time into emulators. For example, Google Cloud, recently they released a few more emulators for their services. For Bigtable, for Spanner, if I remember correctly, and others because they understand that testing during the development is something important. And if 10 years ago it was okay to create a staging environment for testing where you could use the same cloud services, nowadays it's not really an option because you have many, many, many developers, they cannot share the same environment, so they need certain level of isolation. This is where the challenge comes in. And the easiest would be to provide these Docker containers, similar with AWS where they provide DynamoDB local or there is third party product, local stack or project because it's open source project, local stack that gives you emulators for cloud resources. And this is I would say the biggest challenge that we are yet to solve as a community of folks who worry about or who think about integration testing how we can overcome this challenge. And most probably this will require a lot of cooperation with cloud providers, but it's good to see them understanding that this is an actual problem that needs to be solved. They see it as a problem and even though there is this problem, I think overall we are pretty good thanks to Docker because Docker really changed the game. And integration testing before Docker was quite painful because you had to use certain local solutions or embedd solutions for each individual database. So let's say using postgres you need to find embedded postgres. Now using Redis, you need to find embedded Redis. In fact, I myself wrote a plugin for Maven build system for Java that would start and stop Redis for testing. And it was my first experience writing integration testing tools. And later I discovered test containers and never looked back at embedded solutions. But Docker really changed that and now at least most of the databases we can use thanks to Docker. And there is a new TRE Managed services where protocol is open and based on some well known open source database. Let's say aws just released MemoryDB, which is their managed database offering that talks the same protocol as Redis. And as far as they remember they use Redis internally. But that's something that should not concern, something the end user should not think about. But the protocol is there. And Another example is YugabyteDB that talks SQL, talks Cassandra Query language, meaning that in theory for your testing you can test with anything that talks the same protocol and implements the same semantics, which makes it slightly easier. Yes, my application production may be talking to MemoryDB, but since they claim full compatibility with Redis, I know that locally I can start Redis. In Docker view, Redis not just some emulation of Redis, but real Redis thanks to Docker. And then I'm good to go. I know that when I deploy to production I'll be talking the same protocol and it's a similar like similar point compared to where you deploy. You don't need kubernetes to test as long as you're using the same mechanism for configuring your service.

Nice. So you mentioned mocking, you mentioned emulators. Does this all replace service virtualization? I know service virtualization at one time was a hot thing with being able to mimic behavior of a real component. Does this come into play at all with integration testing?

I'm biased here because my experience comes from test containers where we use Docker and we start just instances of real databases, the same basically instances or the same images you would use in production. So it's slightly harder for me to reason about how relevant or not service virtualization, but I believe it depends on the end technology and what it provides or what it does not provide. And while most of technologies nowadays they provide Docker images, there will of course be some legacy databases, legacy technologies that will require something that is not Docker. And I sincerely wish good luck to anyone who have to deal with such technologies because it's quite challenging. And yeah, I hope one day we'll figure out, maybe here at Atomic Jar we'll figure out how to solve, solve it for everyone, not just for Docker users.

Very cool. So we've mentioned it a few times. I don't think we really defined what it is. What is Test Containers? Is it a technology? Is it just a buzzword? Just give folks a little background. What is Test Containers?

So Test Containers is a family of open source projects. It started as a Java project, but then got some traction and we had new versions in Goang, in Python, in Node js, in. Net, we actually have multiple versions in. Net. Then we also got some exotic versions in R. And the most exhausting one I've seen was in Haskell, which is something crazy. But I understand that people, like developers would want to test no matter what language they use. And it kind of like got pruned by all these language works of test Containers. But to define Test Containers, it started as a project that helps testing with Docker, as simple as that. So we have Docker. Docker is a great abstraction, great mechanism for starting thousands, tens, hundreds of thousands of available Docker images for most popular basis, and some exhausting ones as well, given the traction it receives. But Docker is a technical solution, while for testing you need more than just start container. We all know that for testing. I think for me, the most important part about the testing and testing frameworks isn't how you start them, isn't how you start your tasks and your test dependencies, but how you terminate them, how you clean up, how you ensure the isolation and clean environments. And that's what Test Containers helps achieving. Because I myself been using Docker Compose for testing testing, for example. And before testing, on our Jenkins instance, we were doing Docker Compose up and we had our environment running. We had some issues with port conflicts because Docker Compose kind of forced us to use fixed ports because it was external to our test suite. And then after the test, we were using Docker Compose down, a command that would let you destroy the environment. And then one day we start noticing performance regression in our test setup. And apparently on Jenkins, when you kill the job, then it will not, obviously it will not run subsequent command commands, meaning that our Docker Compose down was not getting executed. And we had some dangling containers running and they were polluting our test environments. We were changing database version, so we were getting new containers started. And it didn't really help figuring out what's going on with our testing setup. With test containers, you code your containers during the test. So test infrastructure becomes part of your test of your test code. You literally write new Kafka container, then Kafka start, and you have Kafka running from your code. And this is why I refer to junior developers creating test environments, because they don't need to know how Docker works, they don't need to know how to start Kafka. In Docker, the only things they need to do, they need to instantiate an object. Quite an easy task to do. And to call a method on this object, another easy task to do. And then they have single environment, make sure that you have Docker running and configured, which sometimes can be challenging because of the variety of operation, systems and options how to run Docker. But at least with Docker Desktop, it's no longer that of problem. It used to be a big problem. And this is why in test containers we had multiple strategies for detecting environments, because that's another one. On Mac you would have Docker running as Docker Machine on some random IP address. On Windows it was some other virtual machine. With VirtualBox on Linux it would be native Docker installation. And then you had to spend time discovering Docker and figuring out how do I connect to Docker. Which was quite a big challenge back then. It's not such painful challenge anymore, thanks to Docker Desktop, but still challenge for some. And test containers help with that. So while Docker is a great technical solution for running containers, task containers is missing glue between your test and Docker to start containers, stop containers, wait for them to start. Pluggable strategies, of course, to perform actions on containers. And that's a whole nother story, because test containers we consider it an integration testing library. But then we know that Stream native folks who created Apache Pulls Pusar, they and other Apache Pulsar members, what they did, they created Chaos testing suite for Apache Bookkeeper on top of test containers because they figured that, hey, we have access to creating containers, we have access to networks, we can start stop processes inside these containers. So why don't we design a chaos testing suite for such an advanced thing as Bookkeeper? Because Apache Bookkeeper is really advanced technology. It's stateful, it requires a lot of consensus algorithms and other things. And chaos testing such systems is a big challenge, not something you would usually run on your laptop. But with test containers and the APIs it gives, they were able to do so without any additional features we had to implement in the library. And that's the right level of flexibility. Any library should provide that. Okay, it should not be abusable, but it should be flexible should anyone decide to use it for something else other than the primary use case.

All right, so I might be simplifying this. So does it make configuration of environments easier and automatic? And that's one of the main benefits.

Of it decouples your tasks from environments and makes you think in terms of individual components of your testing setup. So that if you need Postgres, you need Kafka, you need Redis, you start Postgres, you start Kafka. And when I say you start, I mean it, you instantiate it and you tell it to start, meaning that you control it. And then unlike like, so if you Google for example, for something like Docker Compose, how to wait for one component to start after another, for example, you need to wait for Kafka to start before your Kafka connect starts. Then you would end up finding some scripts. And these aren't the prettiest scripts out there because they are hacks. While with test containers you have access to these individual components and you do it imperatively, meaning that you decide when to start what you decide if you want to start it in parallel or sequentially, and it gives you the control. So that unlike end to end test testing or system testing, you don't get a single environment. And usually with single environment you cannot control individual components. You cannot say what happens to my service when one of Kafka nodes goes down. Do I have quorum configured correctly?

That's a great point. So can it help people with reliability engineering then, or Chaos engineering where they can start and stop certain services and see how the application behaves with the test?

That's what Apache Bookkeepers Folks did and. And that's what others are doing. Sometimes they just test their services with three Kafka nodes started. There was a contribution from Akka team members. We're using test containers for checking that their Kafka client works correctly. If cluster like one of the nodes in cluster goes down because you control individual components, then you decide how the individual nodes individual components, then you decide how to start and stop them and what happens if one of them goes down.

I can see this being valuable not only for integration testing, but also I used to be a performance test engine and doing performance engineering and say reliability engineering. This would be a huge help you find all kinds of edge cases, I would think. Am I thinking of it correctly or would that be like more of a modifying it to be something it wasn't created for initially?

It wasn't created for chaos testing or reliability testing use cases. But I can easily see how it can be used and I don't think there is a big problem with that. For performance testing I would be aware of certain things, how Docker works and how test containers works because sometimes some additional proxying is required for you to be able from your environment to connect to a container from the infrastructure because there is still some infrastructure out there. Just you have access to individual components of this infrastructure. But for reliability testing we even have a module called toxyproxy. And toxyproxy is a project created by Shopify, if I remember correctly. And what it gives you, it gives you a chaos testing proxy where you could introduce say latencies or drop every second packet and do many other things to simulate reliability issues and cluster failures. And then you can just put toxic proxy between say two postgres nodes and then check how it behaves. Can even imagine database vendors using, let's say toxyproxy to test reliability characteristics of their solutions or their databases because that's the right level of abstraction they need.

Sounds very cool. I'm getting excited by this. So you obviously have been excited by test containers. I don't believe that you're the one that created, but you seem to be one of the main maintainers of it. I think Richard north invented it. So why I think you're so into it. I think you actually created a company around it. I could be wrong. Atomic Jar. So you talk a little bit about Atomic Jar, how it fits with test containers and how Richard north is involved with this as well.

So let me start with a story how I met Richard and how I got involved into test containers when I was at zero. Turn around Five years ago, more than five years ago, I think now it's six years ago. When we started, we had our own test containers internally. There were some differences of course, but the idea was the same. What if we use Docker API and what if we talk to this API directly from our test and then we start our test dependencies? Because we were testing, testing Java agents and testing of Java agents, especially those that integrate with many databases, is quite challenging. So we created our own library. And then I was browsing GitHub for one of the issues I had with the Docker API library I was using and I noticed the cross reference from another repo and I was looking at some Docker related repo on GitHub mentioning something called test containers. And I had my own testing use case. I was like I should definitely give it a try, I should definitely check what the project is. And I opened the project. I realized that I actually, I think 80% of what we had was already there and it was an open source project by someone I didn't know. But I started looking and I realized that most of the things are implemented the same way as I would do it or as I did it because we had our own library. So I started backporting some of the features we had in our source library because I'm a big advocate of open source as well. I think open source and integration testing are two things that make me passionate about. And I started contributing and Richard eventually invited me to join as a co maintainer. And the library was really small back then. I think it was like less than 100 stars on GitHub and maybe like one and a half user out there other than Richard himself because he created it for his own use case when he was at Deloitte and they had problem with integration testing and they literally had to bring some databases on CDs to install it from one machine to another. And then he realized that Docker is a great technology to use for testing and this is why he created test containers start contributing. We pretty successful working with each other on the open source project. So he invited me as a contributor, co maintainer and I was contributing code. But another thing I started doing since I got so excited about test containers that I wanted to share this excitement with others. So I started attending conferences and started giving talks about test containers and spreading the word. And what was really exciting to see others doing the same. So I was telling someone about test containers and then some developer advocates. For example, early days of test containers we had elastic developer advocates talking about Task Containers because they were talking to their users and their users were telling them, hey, we have troubles running Elastic for testing. Elasticsearch for testing, can you help us? And they had Embedded elasticsearch but it was always quite hard because you had to bring all the dependencies of elasticsearch into your product, into your project, even though for testing, but still. And when they realize that with Task Containers they can outsource this question to another open source project and they don't need to think about it anymore, it was such discovery for them that they started giving talks about Task Containers. They started spreading word and eventually they even announced that they no longer actively develop Embedded elasticsearch because there are some better means of running elasticsearch for testing. So this is how I got involved in the project. It was five years ago and over the course of these five years we never worked Richard at the same company, but we always worked together. And later we also invited Kevin Wittic, our third tener to the team who created Task Containers Spock for Groovy. And he was also super helpful to the project. He was also doing many talks and this idea of starting something bigger for Task Containers, maybe finding some company who would want to hire all three of us. And of course when I was at VMware or previously at Pivotal, I was trying to kind of give them this idea. Hey, maybe given the traction, given that biggest companies out there there such as Google, VMware, Red Hat, Amazon and Whatsnot, Zalanda and others, they're using Test Containers and there are just a few peeks from the top of my head, but there are many more. Maybe you should do it as a VMware project. Maybe. But I think one good thing that Spring team is doing really well is balancing what they do and what they are not doing at this stage. And I completely understand them. But I also realized that okay, if not them, then why don't we start a company company for Task Containers because there is a lot of traction. We have some great ideas for products that would dramatically help Test Containers users because we try to do our best to give them the best open source experience that library can give someone. But there is always something more. There will always be some enterprise customers who would want more. And we are not talking about enterprise support for the library or just selling commercial version of Test Containers. It makes no sense for us as is it stage. But we rather have some SaaS ideas that we'll share later this year. And we started telling this idea to investors. We had Test Containers user who reach out to Us and said, hey, I have certain amount of money and I was so successful migrating to test containers that I think that this is a great solution that will help others. So I'm ready to invest into you folks. Let's give it a try. And we gave it a try. We didn't know what to expect, but we ended up securing a decent funding round of 4 million and we are super happy because now we can finally, first of all, I finally work with Richard in the same company and that's something personal for me, but so happy about it. But also we now know that test containers, we only get better and now we have everything to deliver every idea we had to our users because we really care about our users.

That's awesome. So it looks like it's fairly new. Atomic Jar. So are you still in the early phases and you're just starting to work out your roadmap and rolling it out slowly or how can people learn more about Atomic Jar?

So we started in March, we secured our funding in June and now we are actively working on our product. We are currently in private beta stage and there is sign up link from the main page where you can also sign up for overall announcements or new product announcements. We will be releasing more information about the project relatively soon in a couple of months and we are just going through certain validation stages because we want to make sure that what we want to deliver is exactly what our users need. But we are pretty certain about it now after talking to a number of pilot users. And we will be releasing our first product end of this year. So stay tuned for updates and you can always sign up on atomicjar.com and we will be happy to see more signups because we'll be happy to share news with as much folks as possible.

Awesome. Okay, Sergey, before we go, is there one piece of actual advice you can give to someone to help them with their integration testing efforts or test container testing efforts? And what's the best way to find or contact you?

Okay. My best advice would be that if you ever feel that something that you need is not there, first try to think whether you're doing the right thing. Let's say do you really need need fixed ports? Which is a great example that people ask for but they don't, they don't really understand the implications and that this is not a technical limitation, this is a good practice that we enforce. And then to find the right information, I would always suggest first of all, and it's kind of obvious but to check the docs on testcontainers.org then to reach out to us because we have many active community channels such as Slack GitHub issues GitHub discussions is something new that we recently added with the release of GitHub discussions on GitHub, but that's a great way to ask questions. We of course have our own tag on Stack Overflow and personally, because I know that not every team member of Test Container is so active, but I'm super active on Twitter so you can always find me on Twitter and you can always DM me. It's always open to anyone so feel free to drop a Message on Twitter DMs. It's easiest way to reach out to me me and ask any Test Containers related question. I would always encourage to ask questions in public because then it helps others finding answers to the same questions and they're very rare unique questions. Most of the questions that we getting asked about is something we already replied, so guess googling the answer given the traction Test containers receives is the best approach before asking. But never hesitate to ask if you didn't find answer for a question.

Thanks again for your automation awesomeness. The links to everything of value we covered in this episode. Head on over to testguild.com a363 and while you're there, make sure to click on the Try for Free Today link under the Exclusive Sponsor section to learn all about Sauce Lab's awesome products and services. And if the show has helped you in any way, why not rate it and review it in itunes? Reviews really help in the rankings of the show and I read each and every so that's it for this episode of the Test Guild Automation Podcast. I'm Joe. My mission is to help you succeed with creating end to end full Stack Automation awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Automation Podcast. Head on over to testguild.com for full show notes, amazing blog articles and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.