BACKGROUND
I'm using process.env.<ENV NAME> to set variables in some classes. I need to set them in the tests for the class variables to be set otherwise the test fails.
Currently, I'm setting the variables in a beforeAll() hook. However, there are many test files in which I'll have to set these envs. I don't want to replicate this code throughout all these files if I don't have to.
I decided it would be a good idea to set them up prior to each test through a Jest set-up file. In jest.config.js I added setupFiles: ['<rootDir>/jestSetupTest.js']. Inside this file I added require('dotenv').config(). The .env file is in the root directory.
I've got test files in a couple of different directories: ./src/graphql/__tests__ and ./src/utils/__tests__.
PROBLEM
The envs are being set but they are not being read by any of the Jest tests that are running.
ATTEMPTED
I looked into this issue which got me as far as being able to set-up the env vars, but it has nothing about issues using them.
I've added require('dotenv').config() to the test files that use the envs, but that still doesn't work. This surprised me I thought at least this would set the envs.
I set --debug on Jest but that doesn't show whether envs were set or not.
QUESTIONS
Does anyone know what is going on? Or how I can further diagnose this issue?
I get the impression envs can be set and used in Jest tests, as per the SO post above. Why am I not able to use them? Could it be a config issue with the way my files are set-up?
Maybe you already found a solution. I had my own struggles getting tests to run with the env variables from an .env.test file for my 'create react app'. In the end, all that was necessary was to add the path to the desired env-file in my cmd line scripts in my package.json-file:
"test": "react-scripts test dotenv_config_path=.env.test",
No further configuration was needed.
But there could be some presets going on coming from 'create react app'. I am not entirely sure about this.
So, to get to your question: Maybe you could just put your env variables in a separate file witch you then load through your run-test-script.
Related
I've got installed Cypress on my Vue project and created just a few simple tests that perform great when I run Cypress with this command npx cypress open.
I am trying to implement automatisation with the help of Lambdatest but when I run command lambdatest-cypress run I receive this message in return:
Checking Lambda Config in current directory
Validating CLI
validating config
Error!! Cypress Config File does not exist
I have installed Lambdatest cli globally, added lambdatest-config.json in the root of my project, and updated "lambdatest_auth" data in this file. Also I've got cypress.config.js on the same root level in project's directory. Cypress's config file does not show any errors excluding eslint saying that
on this part
setupNodeEvents(on, config) {
// implement node event listeners here
},
on and config are declared but never used.
Do you have any ideas why I can not run this one using Lambdatest?
As always maybe someone will find it useful.
So... it would seem that in some cases lambdatest get's a little bit lost and it's config is not filled with the things it should be :)
The solution was to remove this line of code in lambdatest-config.json file which is located in the project root directory.
"cypress_config_file": "cypress.config.js", <-- remove this line
We have a script "build": "rollup -c rollup.js --environment production", which when called by some of our team (who use Windows) will on occasion spontaneously not run as normal, but instead just open up the rollup.js config file in an editor. Unfortunately I don't really know where to start with this because I've never been able to replicate it. No logfile is being produced and as far as I've been told ignore-scripts is not set, which are the only other things I've seen related to this behaviour on SO.
Is this a known thing that there's a simple fix for? Or if not, where should I go to find more info about this? Would this be an issue with npm, or with rollup?
I encunter the same sutiation on Windows.
I bypass it by using WSL.
Through some investigating I've tracked this down to what I believe to be a rollup bug with regards to how they're processing their config files. I feel as though I should open a ticket with them regarding this but I've been acting on behalf of a team member and don't have the ability to replicate it on my own, so... I suppose I'll try and coerce them into doing it.
But anyways, so from what I can tell looking at rollup's source, if a rollup config file has a plain .js extension, then it looks as though rollup is running itself on the config to convert it into a CommonJS format, which it will then import and use on the actual build step. Somewhere in this process on Windows something goes awry and the result is that the config file just ends up getting opened with whatever the default handler is for JS files. So basically the solution is to change the file extension.
Our original config was set up using ES6 import/export, and I'm unclear at this point whether changing the extension to .mjs will skip or otherwise change this conversion step, it seems to have worked as such when people have tried it but I can't vouch for it. What I did was to instead go through the config and manually convert all the ES6 import/exports to CommonJS require() and then change the file extension to .cjs (hence our config changed from rollup.js to rollup.cjs) and now it appears to be working consistently across the board.
I have a Vue.js app hosted by AWS Amplify.
In Vue, env vars can be set application-wide by using .env. files.
I currently use such files for development and for production modes, containing different values.
When locally building and serving my application the above works as expected. However, once Amplify deploys my app (in my case I use Amplify's CD feature), these variables are not defined.
I know I can define the same env vars in Amplify, but that would mean I need to manage these values in two places since won't be redeploying while developing. so this seems to be prone to errors (I will need to remember to update the vars on both the application end and amplify console whenever I need to make a change for example).
I wonder if this behavior is expected or is there something I am missing in my setup.
Thanks!
I was also facing the same issue in my React app.
The thing is, you need to have a .env file in your app with all the environment variables.
Why? — The reason behind that is, it generates static HTML, CSS and JS files. Those files can't access process during the runtime.
After adding all the environment variables in Amplify, you have to add one more command in your build stage in App build specification.
You can refer to this official documentation on how to implement this.
If you don't care much about your environment variables, you can use this hack: printenv. This will store all the environment variables of your OS and your application in the .env file.
My config looks something like this:
build:
commands:
- 'printenv >> .env'
- 'npm run build'
This question is not about .env files, thank you.
It says in the docs:
In addition, environment variables that already exist when Vue CLI is executed have the
highest priority and will not be overwritten by .env files.
Well, I added a system variable VUE_APP_TEST = "test value"
And then rebuild an application adding following code
console.log(process.env.VUE_APP_TEST)
To no avail, obviously
So the question is, am I doing something wrong, or just overestimating VueJS capabilities, or docs are wrong, or I am misunderstanding the "already existing variables" part?
UPDATE:
Yes, I stoped the npm run dev and started it again before asking this question. It works well for variables in .env files. But the question is not about the .env files.
Restarting the system did help. But this is beyond my understanding why vue-cli didn't catch changes in the environment any other way. Should've checked if it's actually a vue-cli issue or is it windows who don't update the environment until restart (weird).
I am currently running Cypress and I have folders inside of it, where I have tests located for different applications.
I have a folder entitled "smhw-qa" which contains sub-folders and tests files for this specific application.
This directory apps will also include other applications too in future.
What I wish to do
In order to avoid having to run every test for a run, I wish to only run this specific folder. The location of the folder is as such:
'cypress/integration/apps/smhw-qa'
Over time, there will be more folders and tests added to the apps directory.
I am familiar with how to run a specific file, so doing the following works:
npx cypress run --spec 'cypress/integration/apps/smhw-qa/banners_promos_global/global_search.js'
How can I specify to Cypress which folder to run specifically when I use the npx cypress -run command?
What I have tried already
To run a specific test file I tried:
npx cypress run --project 'cypress/integration/apps/smhw-qa'
But this provides an error instead:
Can't run because no spec files were found.
We searched for any files inside of this folder:
/Users/jaswindersingh/Documents/cypress-automation/automation/cypress/integration/apps/smhw-qa/cypress/integration
Running specific sets of tests by their folders will be much easier for me, and will save time when running a specific suite of tests on our CI platform for example. I will also not need to specify the individual files since this is time-consuming.
It would also mean I can split out my tests and run them on different machines
Do I need to put anything into my test files, or inside of cypress.json or modify anything else, or can this be achieved through the terminal?
What options must I use instead?
Thanks
I think the clue is in the error message, you call
cypress/integration/apps/smhw-qa
and the error message shows
cypress/integration/apps/smhw-qa/cypress/integration
so to use the --project flag you need to replicate the /cypress folder per project, as per this example cypress-test-nested-projects
Folder structure:
package.json
node_modules
src/
clients/
foo/
cypress.json
cypress/
bar/
cypress.json
cypress/
However, I think you might want to use the --spec flag instead. If I understand it correctly, the glob pattern will allow you to keep the current folder structure. Docs
cypress run --spec 'cypress/integration/apps/smhw-qa/**/*'
Through --project you can manage different cypress.json files, the docs says
This enables you to install Cypress in a top level node_modules folder but run Cypress in a nested folder. This is also helpful when you have multiple Cypress projects in your repo.
so you're on the right way, just prepare some project-related cypress.json files