Database connection and parallel tests
Get the project source code below, and follow along with the lesson material.
Download Project Source CodeTo 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.
Lesson Transcript
[00:00 - 00:33] In this lesson, we'll continue from where we left off in the previous lesson, where we discussed running tests sequentially with tests. We will focus on enhancing test isolation by making changes to the applications database connection and port configuration. To ensure test isolation, we'll make a slight change to the MongoDB URI in the app.js file. By modifying the database connection, we can guarantee that each application instance uses a unique database.
[00:34 - 01:52] Here's my app.test.js and the copy that I created in the previous lesson. And I also have my app.js file. The first change that we need to make is to check if the environment is the test environment and then append the just worker ID to the MongoDB URI. In this example, we check the value of the node environment variable. If it is set to test, the application will connect to a test specific database. But before doing that, it appends the just worker ID 's value to MongoDB URI. The just worker ID is a unique identifier assigned to each worker process, helping you differentiate them in your test. If you have three test files running concurrently, each of these three test files will have a different worker ID. When running tests sequentially, just uses only one worker process, assigning its just worker ID value of one. By altering the MongoDB URI, as we have done here, this ensures that each application instance has its own isolated database or a unique database. Let's run the npm test script again.
[01:53 - 02:15] We can see that we have one failed test suite. And to investigate further, here is the error message. Address already in use. This means that the application is in use by more than one test suite.
[02:16 - 03:23] And the application has been configured to listen on port 3000. At least one of these tests will fail because the application is already listening on port 3000. And the new application is trying to listen on that same port, which is already in use. Because we have different copies of up.js, we have up.to the JS up.to the JS. The change I've made is to increase the port number for each up file. In up.to the JS, we have 3002 and in up.to the JS, it is listening on 3003. With this, we are guaranteed that each application will listen on a unique port and we won 't have two applications trying to listen on the same port. I'll go ahead and run our npm test script again. And now all our tests run successfully without failing. To summarize, we've made changes to enhance test isolation by modifying the database connection based on Node-NV and just walk our ID.
[03:24 - 03:38] We also ensured that each application instance uses a unique port. We prevent port conflicts between application instances. These changes promote better isolation and reduce potential interference between tests.
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.
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](/_next/image?url=https%3A%2F%2Fs3.amazonaws.com%2Fassets.fullstack.io%2Fn%2F20240214201947577_AkinwaleHabib_PainFreeMockingwithJest_1450.67x816_CoverImage.png&w=3840&q=75)