You NEED to start using test containers!

And great news, gang. I just got a new job. You see, I'm actually all set up here with this Ruby on Rails project for my new job. I have all of my gems and dependencies installed. So, let's go ahead and run my tests. Run bundle exact rspec spec. And oh, I'm seeing errors. What is this? H I don't have Postgress setup. Man, that's going to take forever. I guess I might as well quit my job. >> Hold on. Whoa. You don't have to quit your job. Um, who are you? >> I'm you, but from the future. >> Oh, yeah. You look just like me. >> Well, yeah, of course I would look like you. I I am you. Just from the future, like I said. >> Oh, right. Listen, you don't have to manage your dependencies locally in test. You can use something like test containers. Test containers, huh? I guess I could look into that. >> Okay, great. Use test containers. I have to go save my family from my OpenClaw installation. It's going crazy. >> OpenClaw? I've never heard of that. You mean wait, Claudebot? >> No, it's called OpenClaw now. They change the name a couple of times. You'll figure it out. Use test containers. Oh, okay. Good luck. Let's talk about test containers. Oh man. So, it's been a couple of days. It turns out I decided to help future me with their open claw installation, and it was crazy. That's a subject for another video and to be honest, I don't think I want to talk about it. But anyways, let's save current mi's job by installing and learning about test containers in this Ruby on Rails project. But first of all, what are test containers? Well, test containers is an open source library for providing throwaway lightweight instances of things like databases, uh, Reddus, web browsers, anything that can fit [music] in a Docker container. Now, if you don't know much about Docker, don't worry. We have other videos on Docker on this channel, including an intro to Docker. So, go check that one out and then come back here. So, basically, when I want to spin up a test container, I can click on this Ruby example here because I'm using a Ruby on Rails app for my new job. I can see down here if I want to start a Reddus test container, it is just test containers docker [music] container new and I call with exposed port. Now, this is pretty great syntax, but it can get even better than that. You see, test containers also have something called modules. Now, modules provide basically syntactical sugar on top of test containers to make it even easier to create the test containers that you want. Now, you can see this syntactical sugar in action here. If I search for something like say Reddus and I click on Python, I can see that this is a lot more simple than spinning up a raw Docker test container using Python. Let me just go back to the Python example here and I'll show you what I mean. If I [music] click on Python, we can see that this Reddus incantation is actually a little bit more complicated. So modules are the way to go if you have them available. Now, one thing I noticed that in the modules section of this website, I don't see any examples for Ruby. However, if I go to the Ruby GitHub repository, I can actually see that there are modules in the Ruby GitHub repository. So, if you're on a Ruby on Rails app the way I am, there are modules for test containers for Ruby. They're not on the website, at least not yet, but they show up in this repository and that's what I'm going to use for the examples I'm going to show you today. Now, if we remember from earlier in the video, if I run my specs, Total Exec spec in this new project, I get a ton of failures basically saying that Postgress is unavailable. Now instead of installing Postgress locally and potentially running into issues with a different version of Postgress locally than on CI or in production, I can use a test container. So let's go ahead and install the [music] test containers Postgress gem which is the module in Ruby for test containers for Postgress [music] and set it up for my project. I can go to the repo here, click on Postgress and I see I have a nice little thing I can copy and paste into my gem file. So let's go ahead and do that. I can go back to my project, open up Neoim, go to my gem file and somewhere down here I will just paste what they have for Postgress. In my test group, I have test containers Postgress. Great. So now I can run bundle install and everything is installed. I now have test containers Postgress. Awesome. Now with a lot of Ruby on Rails projects, especially ones that use RSpec, we actually have a file called Rails helper. And we can see in this file we actually include every file under the spec support directory. So let's create a new file under spec support so that we can put all of our test container information into it. Let's create a new file spec support test_containers.rb. That seems good. So in this new file I'm going to create a new module called test containers. This is going to allow me to reference test containers throughout my configuration. I'll explain that as we go along. In this module, I'm going to define an adder accessor for Postgress. This gives me the ability to type test [music] containers.postgress. And then what I can do is I can instantiate a new container in this module and then talk to it from outside of the scope. So let me explain what we're going to want to do here is we're going to want to configure RSpec. And inside of this configuration block before our test suite runs, we're going to want to create a new test container for Postgress. You can actually see here that the [music] uh syntax for that is test containers postgress container new. And so what we can do is in our file we create a new [music] Postgress test container and we assign it to the Postgress attribute on our test containers module. This allows us to reference it elsewhere throughout this configuration. And what we're going to do here is use Postgress version 16. Next we want to do is actually start our Postgress container. And then we're going to want to do a couple of configuration things. We want to make sure that active record is actually talking to our Postgress container as its database and we want to run our migrations before our suite. So let's save this file and then I want to open up docker so I can see what's going on here when I run my tests. So now let's run bundle exec rspec spec and we should see a new container spin up and yep there it is. That's our Postgress container. It runs our migrations and then it runs our specs. And let's see here we still have some failures. Oh, it looks like we don't have Reddus running. Well, that's okay. We can actually [music] accomplish this by using the Reddus test container. But first, actually notice something. We can see here that our Docker container for Postgress is still running even though our test suite ran. Which means that every time we run a new test suite, we spin up a new Postgress container and the old one is still running. See, I don't like that. So, what we're going to have to do here is configure RSpec to actually delete and stop our Postgress container. This is why we use that module up above is so that we can reference it later in this configuration. So after [music] suite in our RSpec configuration, we want to stop our Postgress container and remove it. So now let's write this file and we can go over to docker, we can stop this container and stop this container. Delete it. Delete it. And if I write this file and run bundle exec rsp spec spec, we should see that we spin up our container. And when this test suite is done, our container is now done. Awesome. We now have a lightweight throwawayable container for Postgress to run whenever we run our specs. Nice. But of course, we see that we still have errors for Reddus not running. So let's solve this with test containers. In the repository, we actually see here that we have a Reddus test container and we have some documentation on what to do here. So let's copy and paste this gem line into our gem file. Let's go to gem file. We can go down to our test group that we made before and we [music] just paste test container reddus. Awesome. So now we can run bundle install. And now reddus for test containers is installed in our [music] gems. So now let's go ahead and use reddus as another test container to run alongside Postgress. What we want to do is add another adder accessor that will allow us to access the reddus attribute on this module. Then we're going to want to go ahead and create a new Reddus test container. That's pretty simple. It's very much the same as how we do it in Postgress. Test containers. Reddiscontainer new. And we're using Reddus 7 for this. Now, a lot of people will be using Vuly. Now, that's probably what you should be using because Reddus had this whole open- source closed source issue earlier this year. But for now, let's just assume that this project uses Reddus. We're also going to want to start our test container before the suite. And we're going to want to do a couple more configurations for Rails. We want to make sure that Rails is using this new Reddus instance in [music] test by making sure that the Reddus constant in our application is pointed at the URL for our new Reddus test container. Also, we want to make sure that our application cache store is this Reddit cache store with that URL. And we want to make sure that our lookup store is also set to the same thing. We also want to make sure that we stop and remove our Reddit test container just like our Postgress one. So in our after suite we want to make sure we call reddus.stop and reddus.reove. Now if we write this file and then run our whole entire test suite we can see that actually let's pull up docker as well here we can see that docker runs two containers that actually went really fast and then it deleted them. So let's run it one more time. We see we spin up postgress then we spin up reddus and then we run all of our specs and then everything gets thrown away. This is incredible. But you see, there's one more thing I want to talk about with test containers. Test containers are amazing to use in CI and they're amazing to use locally because you can actually point your versions of your local dependencies to whatever is in production. So let's just say that locally I had Reddus 5 installed. I can actually change this to use Reddus 5 for my test container instead of Reddus 7. What would happen if I had a version mismatch? This is one of the best reasons to use test containers at least locally. Now, if we had a version mismatch between our local instance of Reddus and what we use in production and in CI, it's possible that there are APIs or functionalities on CI or in production that we don't actually have locally. Now, we can change our versions of Reddus in our test containers to make sure that we match what we have. But if locally we didn't have the right setup, this is something that could happen to you. Let's actually open up a new pane and we can run bundle exact rspec spec. If we run all our specs, we can see that we actually have a failure. This failure is in the LM pop spec. If we scroll down, we can see that we're actually using a new feature of Reddus in Reddus 7 called LM POP, but that's not available in Reddus 5. So, that's something that could happen to you and you can get bit if you're using the wrong versions of things on your local machine versus CI or production. So now if we update our version of Reddus to Reddus 7 and we run our suite again, we can see that all of our specs pass [music] as they did before. Now this is extremely powerful. I love test containers. They're very lightweight, very straightforward, pretty easy to use, and they're amazing. Don't get caught using the wrong dependencies locally as opposed to what's on CI or in production again because you can use test containers to manage this for yourself. Subscribe to this channel for more Docker, Vim, Bash, and Linux stuff. And hey, thanks nerds.

LEARN: https://learn.typecraft.dev/ X: https://x.com/typecraft_dev Lets say you’re a developer, and you’re starting on a new project. You get all the source code, you install the libraries you need, you’re on the right version of your language. So you go and run the tests and…. woops POSTGRES ERROR BUT WAIT, what if there is a simpler way to do this? You can see, i run my tests, and I see new docker containers spin up out of nowhere! then they shut off! what is this magic? well, its testcontainers. And in this video I’ll explain what they are, how they work, and why they’re so friggin useful. so grab your containers, we’re going in!