Mock Web APIs with Testcontainers in Go

Рет қаралды 2,087

Күн бұрын

#golang #coding #testing #integration #api #tutorial
In this video I show you can spin up custom docker images using Testcontainers automatically in your integration tests, and I show how you can easily spin up a custom web API inside the container to integration your code.
This is a great way to make your integration tests do almost anything, you have the power of Docker at your fingertips and can mock most anything to test properly integrating with it.
Testcontainers is an open source framework for providing throwaway, lightweight instances of databases, message brokers, web browsers, or just about anything that can run in a Docker container.
testcontainers.com/

Пікірлер: 10

@eldr-io 26 күн бұрын

The repo for the code in this tutorial is here: github.com/sigrdrifa/testcontainers-go-api And the editor I use is Neovide (neovim), the config is here: github.com/sigrdrifa/nvim thanks for watching!

@Difcar 19 күн бұрын

A really clear and easy to follow explanation! Thanks :)

@NeuroDrizz 26 күн бұрын

Pretty cool, elegant implementation.

@jswlprtk 27 күн бұрын

Your neovim config is amazing! Looks very similar to the Lite-XL text editor. Is there a place where I can find your neovim config(dotfiles)?

@eldr-io 26 күн бұрын

Sure thing, see the pinned comment

@raptorate2872 27 күн бұрын

Thank you for this approach, i wanted a way to automate container tests that i was doing manually or through shell scripts remotely. With test containers, i could fire them up against live containers (pods) via kubernetes.

@SayfSentinel 27 күн бұрын

Hi, i like the content, I'm a bit confused about the file path for the testcontainers.ContainerRequest... the file path is "./test/integration/test-server/Dockerfile", but the dot means the current directory but the file is inside integration folder...😕

@eldr-io 26 күн бұрын

Hey, yea its a bit confusing but it's actually because that path is relative to the build context of the ContainerRequest, which we've set to the root of the project, and so the dot resolves to the project root and therefore we need the full path to the Dockerfile (from the root). Hope that makes sense