Parallel tests and database connection

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.

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 - 01:26] In this lesson, we'll be exploring how Jest runs tests in parallel by default, and the benefit it brings to test execution speed. However, we'll also discuss a potential problem when tests are not well isolated. Jest runs tests in parallel by default. Parallels means that Jest uses different threads to run each test simultaneously, resulting in faster test execution. Let's consider an example. Suppose we have three test files, each taking one second to run. If we run this test in parallel, it will take approximately one second to execute all three tests as each test is running concurrently. When you run the just command, the tests run in parallel by default. Running tests in parallel can become problematic if the tests are not well isolated. For example, if the tests share state, such as using the same database collection, they may interfere with each other's execution. Let me demonstrate this with our test case. Here's one of our tests suite. I'll execute the npm test script and see all tests passing before I make any change. And we can see that all our tests run successfully. Next, I'll create a copy of our app.test.js and run the npm test script again.

    [01:27 - 02:01] Running the npm test script again results in some failing tests. In one of the failing tests, sign up route, giving user in request body creates user in database.

    [02:02 - 03:08] We can see that the test expects one and it received two. And this has to do with the users in the database. As you can see, the tests that rely on shared state are failing when executed in parallel. This interference occurs because the tests are not isolated from each other. To address this issue, just provide the solution. We can use the run in band flag to run tests sequentially, ensuring that each test runs in isolation. By running the tests sequentially, we avoid the problem of shared state interference. Now the test will run one after another ensuring proper isolation and passing results. In the terminal, I'll run the npm test script and pass the run in band flag.

    [03:09 - 04:09] In the npm test script, using the run in band flag, proper isolation all our tests run successfully. By running the test sequentially, we avoid the problem of and passing results. In summary, just run tests in parallel by default, providing faster test execution. However, when tests have a shared state, such as using the same database collection, running them in parallel can lead to interference and failing tests. In the next lesson, we'll explore techniques to properly isolate tests to avoid such issues.