Introduction to test containers

Project Source Code

Get the project source code below, and follow along with the lesson material.

Download Project Source Code

To set up the project on your local machine, please follow the directions provided in the README.md file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.

Table of Contents

This lesson preview is part of the Pain Free Mocking with Jest course and can be unlocked immediately with a \newline Pro subscription or a single-time purchase. Already have access to this course? Log in here.

This video is available to students only
Unlock This Course

Get unlimited access to Pain Free Mocking with Jest, plus 70+ \newline books, guides and courses with the \newline Pro subscription.

Thumbnail for the \newline course Pain Free Mocking with Jest

  • [00:00 - 00:15] In one of the previous lessons, we discussed the need to have a test-specific database. If you don't use a separate database between testing, development and production environment, there's a risk of unintended side effects like data loss or corruption.

    [00:16 - 01:00] As a best practice, we never want to run integration tests against databases containing important business data. We're running tests in a CI/CD pipeline that is continuous integration, continuous deployment, where your local MongoDB database won't work. You can provision a hosted database instance, specifically for testing, that can work, but at least requires you to create that database first. If in the future that database instance is unavailable when your tests are running, then your tests will fail, even though the test cases and the system on the test have not changed. Test containers allows us to automatically start disposable instances of databases or other services right before our tests run.

    [01:01 - 01:25] These include images like Postgres, MongoDB, RabbitMQ and more. With test containers, you can have consistent testing experience both locally and in CI/CD pipelines. As a fun fact, the company behind Docker recently acquired AtomicJaw, the company behind test containers. This happened a few days before this recording.

    [01:26 - 01:58] This accusation by Docker shows the growing popularity and acceptance of test containers as a standard testing tool. It provides the confidence that the projects will continue to get the needed support. Overall, test containers improve reliability by a line test to run against through a database starting each time in a non-clean state rather than depending on existing production data. In our next lesson, I'll demonstrate how to set up test containers and integrate them into