Lessons Learned
Context:
Express API, Vite/React frontend, Postgres DB. They each run in their own containers and are coordinated locally with docker-compose. This containerization is both for local development purposes and to prepare for OpenShift deployment.
Problem:
After initiating Jest with basic configuration and creating a basic test, the error SCRAM-SERVER-FIRST-MESSAGE: client password must be a string showed up when running the test with npx jest.
Troubleshooting:
From the above screenshot, we can see the error seems to be related to the pg module not connecting due to a password issue. This was confusing because the API was connected and successfully querying the DB from this point in development, so I knew for a fact it was getting the correct credentials in the container.
Looking for solutions on the pg package documentation was not useful, since my understanding of the reason for the error was misguided to it. I didn't pay attention to the fact I was running Jest from my host system's shell and the API was running in a docker container. The project is set up so docker-compose sets the environment vars when we run the project with docker compose up --watch. But since Jest was being launched from the host system, it would use the host environment variables.
Solution:
Once @LocalNewsTV pointed me in this direction, I set Jest to run with dotenv so it would properly load the environment variables in ./.env. The package.json test script was set to run with "test": "jest --setupFiles dotenv/config", to ensure it sets up the environment variables in ./.env.
Lessons learned:
- Pay attention to the error context, not just the message itself.
- Think of what was changed since the error started showing up.
author: @Kcaparas
Context:
Me and my Co-developer Gui decided to both use Jest on both Frontend and Backend. Without further researching about how Jest works, I've went around and look for some guides on how to install Jest, and how to use it. I've first started creating simple tests such as checking if that context is true! Very simple indeed. Then proceed to mocking axios to fetch data and be able to test if that returned data by axios is exactly NMP API is healthy and ready!. However, Jest suite test returned me this error first. meta-property is only allowed when the '--module' option is 'es2020', 'es2022', 'esnext', 'system', 'node12', or 'nodenext'.. After a few configurations and installing jsdom, I got an error of import.meta.env. returns undefined when I've console.log it.
Problem:
Jest Suite tests fails when trying to test if text appears in the document.
expect(screen.getByText('NMP API is healthy and ready!')).toBeInTheDocument();Troubleshooting:
After a series of researching and a series of frustration. I've tried configuring a lot of files(too many to discuss everything.) in order to find the correct solution for the Jest Problem for frontend.
Solution:
- Used Vitest instead of Jest.
Lesson Learned:
- Research further before implementing. You'll lose a valuable amount of time if you fail. However there are good merits on it. Since you learn from your mistakes.
Pull Requests are a great way for our peers to review how we're solving an issue. It can help us catch mistakes early, before code is deployed. It also ensures we are following best practices in coding and holding each other accountable for our contributions.
Long PRs make this process more complicated, adding too much information and context instead of highlighting what's most important about your changes. It also opens up too many loose ends to be fixed in case there are issues in the contribution.
A good PR should be bite sized, probably under 500 lines of changes, most likely not over a thousand 👀. There should be helpful descriptions and all the information necessary for a reviewr to understand the problem to be solved and if it was actually solved.
We should strive to write short, descriptive PRs with clear issues and resolutions. This posture is definitly helpful to achieve better quality code and product.
@GDamaso