Consider configuration below
"default": {
"selenium_port": 4444,
"selenium_host": "localhost",
"silent": true,
"screenshots": {
... },
"desiredCapabilities": {
... },
"globals": {
"url": "http://localhost:8080/myapp",
"user": "user",
"password": "pass"
}
}
Assuming 'myapp' is deployed on another (dev/staging) server and has another password it would be very cool to override default using command like option like this:
nightwatch -Gurl=http://dev:8080/myapp -Gpassword=pass
This will simplify running the same script across different servers and simplify integration with CI servers like jenkins.
I know that there is globals_path option to specify globals, but it's not optional, if I specify it to be "~/nightwatch-globals.json" for example, it will force everyone to create that file (and keep in sync) after fresh project checkout. Making this parameter optional may also work (if the file is present if will overwrite the default globals)
Have you tried creating a second environment and overwrite them in there? Something like:
"second": {
"globals": {
"url": "http://localhost:8080/myapp",
"user": "other-user",
"password": "other-pass"
}
}
The only problem would be the "globals" object would be overwritten completely and not extended.
Assuming 'myapp' is deployed on another (dev/staging) server and has another password it would be very cool to override default
Afaik you could use ENV variables in your config and set them before calling the script.
"globals": {
"url": "http://localhost:8080/myapp",
"user": "${ENV_USER}",
"password": "${ENV_PASS}"
}
$ ENV_USER=john ENV_PASS=doe nightwatch -t ...
I'm not sure about the (correct) syntax but iirc i've read somthing like this..
regards
~david
Yeah that also works.
On Monday, June 23, 2014, David Linse [email protected] wrote:
Assuming 'myapp' is deployed on another (dev/staging) server and has
another password it would be very cool to override defaultAfaik you could use ENV variables in your config and set them before
calling the script."globals": {
"url": "http://localhost:8080/myapp",
"user": "${ENV_USER}",
"password": "${ENV_PASS}"
}$ ENV_USER=john ENV_PASS=doe nightwatch -t ...
I'm not sure about the (correct) syntax but iirc i've read somthing like
this..regards
~david—
Reply to this email directly or view it on GitHub
https://github.com/beatfactor/nightwatch/issues/184#issuecomment-46884875
.
I did not know about ${ENV}, will give it a try, it should work.
In general, having 3 configurations like "firefox, chrome, ie", I want to avoid having 6 of them just because of local/dev environment.
Thanks.
${ENV} approach works, but it's very bad user experience, you need to know some magic to construct the command line rather than just run nightwatch with defaults and be able to overwrite them.
I'm renaming the issue to be more generic, another use case is to be able to overwrite any configuration parameter like:
nightwatch -Gselenium_host:4445
I have to admit, that the usage of ENV vars fits more into an _ci/task-runner_-environment..
With a task-runner like _grunt_ it should be fairly easy to implement your use-case.
One situation where config files suck is when I've just installed a fresh server that I want to test. It has a DHCP address that changes for every test iteration, and is only known at run time, as in:
ipAddress=createServerEgWithPuppet
nightwatch -GipAddress=$ipAddress
Where currently I can do this instead:
ipAddress=createServerEgWithPuppet
ipAddress=$ipAddress nightwatch
And then I'm good to go. But it _is_ a mess to have two separate name spaces for _"global variables"_.
Hi all, i am working on automation scripting using nightwatch i would need inputs for below two queries
For example: I need to select a country while registering to an account in the application.
our requirement is to run the script by passing the country value from command line , i.e run a script to create account by passing the country value from command line.
i did a workaround with global var but could figure out a way. please let me know if there is any way to pass the country value as parameter to the test case
Most helpful comment
Afaik you could use
ENVvariables in your config and set them before calling the script.I'm not sure about the (correct) syntax but iirc i've read somthing like this..
regards
~david