Environment: custom variables

[vinogradoff]

Is there a way to put (and read) some custom variables in environment part of settings.json?

For example, you would like to have different test-site urls for production and staging.

[davidlinse]

you can have different environment settings in your nightwatch.json. Does is not fit your needs ?

regards
~david

[beatfactor]

I think @vinogradoff is referring to having properties defined in your test_settings available inside the test. What you need is the launch_url property.

In your test refer to is as client.launchUrl. There isn't support yet to add other properties, but I think it might be useful to have that.

http://nightwatchjs.org/guide#settings-file

[vinogradoff]

That almost surely does fit but I need a hint how to use it :-).
For example I want to put "my_own_url":"www.own.com" for "default"-env and "my_own_url":"staging.own.com" for "staging"-env.

"test_settings" : {
"default" : {
...
"desiredCapabilities": {
...
},
"my_own_url":"http://www.own.com"
},
"staging" : {
...
"desiredCapabilities": {
...
},
"my_own_url":"http://staging.own.com"
},

How can I reference it from my test script main_page.js? starting ./nightwatch -e <staging | default>

[vinogradoff]

@beatfactor cool! it is working fine, I think the docs were not so obvious at this place, that you might just get client.launch_url resp. browser.launch_url as string :-)
Thanks I made the next step forward :-) Now I need to read out credentials, not basic auth, just for the form, which are different in 2 environments. Can I just define any variables and they would be wired in browser.var_name?

[vinogradoff]

tested. looks like only launch_url is explicitly wired. Perhaps a Bag with custom variables as improvement?

[vinogradoff]

I'm not programming seriously since a few years, but could it be that
in this code from init.js we need just add the last string?

this.options = options || {};
this.api.launchUrl = this.options.launchUrl || this.options.launch_url || null;
// backwords compatibility
this.api.launch_url = this.api.launchUrl;

this.api.custom_vars = this.options.custom_vars;

And config like:

"default" : {
  "launch_url" : "http://www.google.de",
  "custom_vars": {
           "myuser : "user_prod"
  },
 ....

And call like:

var username=browser.custom_vars.myuser;

Not?

[dmarquezz]

@beatfactor I talk about it in https://github.com/beatfactor/nightwatch/issues/86, but there used to be support for custom environment variables before v0.4.1 by calling the options property on a client object.

You could specify custom, environment specific variables in test_settings, and access them by doing something like client.options.custom_variable.

The options property is no longer available with v0.4.1 though. Can a possible solution to this be providing an options property to the client object again?

[vinogradoff]

thanks @dmarquezz, I must admit, I am cowardly using 0.3, as it worked so fine for me :-)

@beatfactor have I already told you, that nightwatchJS is just brilliant? Thank you!

[beatfactor]

@vinogradoff thanks a lot!
@dmarquezz I see, I'll fix the problem by adding a "Bag" of variables in nightwatch.json. I think it will provide better stability overall by not exposing the settings.

[dmarquezz]

@vinogradoff you're right, Nightwatch is pretty awesome. @beatfactor thanks a lot. that will be really useful.

[beatfactor]

@vinogradoff that's close enough (i.e. your code example).

[beatfactor]

I've added support for a "globals" property. It can be defined either inside the test_settings environment or on the top level as an external module, as seen in the sample nightwatch.json:

"saucelabs" : {
  ...
  "globals" : {
     "myGlobal" : "some_sauce_global"
  }
},

or

...
"globals" : "./examples/globals.json"

[beatfactor]

can i close this?

[sabind]

Looks good.

How do you include the globalModules.js instead of the globals.json?

[beatfactor]

the same way.

[sabind]

Got it working. super wonderful awesomeness.

[apanashchenko]

Hi guys,
Can you please share example how to use custom variable, because it's doesn't work for me!!!

[davidlinse]

what about sharing the setup that doesn't work for you?

[apanashchenko]

I try added
"custom_vars": {
"myuser : "username"
},

and use client.options.custom_vars.myuser but TypeError: Cannot read property "custom_vars" or undefined

[davidlinse]

I've added support for a "globals" property. It can be defined either inside the test_settings environment or on the top level as an external module, as seen in the sample nightwatch.json:

@apanashchenko Did you read this.. ?

[GrayedFox]

Hey sorry to boot up an old thread, but I am having trouble. I have read and re-read the docs - not sure what is going on. In my nightwatch.json I have this:

"globals": "./lib/globals.js"

However, when calling this at the start of a test:

before: function(client) {
    console.log('Pretest output... Some global = ' + JSON.stringify(client.globals));
  },

I always get an empty object. Going any deeper (i,e. client.globals.userName), unsurprisingly, returns undefined.

Why wouldn't this work? Any help is really appreciated. Thanks to all.

[GrayedFox]

Of course, the moment I post this, I get it to work.
This is the correct path to my globals.js file: "./lib/globals.js" -- however, using this path only works when listed under the "globals_path" section in the nightwatch.json file.

If listing it under the "globals" section (under "test_settings") it will silently fail to properly find the globals.js file. No error is thrown (i.e. nothing about not being able to locate the globals.js file appears in the debug output) and JSON.stringify(browser.globals) returns an empty object at run time.

Hopefully this helps future nightwatch users... if specifying a file, and not an object, to use globally throughout your tests ensure it is listed under "globals_path" and not "globals".

[kavimukh]

Hi,

I have more then 1 user and respective password. e.g. user1 / tester, user2 / tester, user3/tester etc.

and I am expecting my script should run against all user. I will go for this?

[timkellogg]

Is it possible to load ENV vars that are meant to be hidden from version control? I want to reference a user's credentials that are kept in a dotenv file and putting them in the globals will require them to be strings thus exposing them.

[aamorozov]

+1

[RobertBolender]

Since I'm not the only one who found this issue by googling "nightwatch environment variables", I will share how I managed to get dotenv secrets loaded in my nightwatch configuration.

nightwatch.json

...
"globals_path" : "globals.js"
...

globals.js

module.exports = {
  before: function(done){
    require('dotenv').config();
    done();
  }
}

.env

SECRET_CODE=1234

Add node-dotenv to the project with npm install dotenv.

Now the secret code is available within my test suite with process.env.SECRET_CODE

[mdharamadas]

What if you have different variables for different environments?

…

On Tue, Apr 4, 2017 at 4:01 PM, Bob Bolender ***@***.***> wrote: Since I'm not the only one who found this issue by googling "nightwatch environment variables", I will share how I managed to get dotenv secrets loaded in my nightwatch configuration. nightwatch.json ..."globals_path" : "globals.js"... globals.js module.exports = { before: function(done){ require('dotenv').config(); done(); } } .env SECRET_CODE=1234 Add node-dotenv to the project with npm install dotenv. Now the secret code is available within my test suite with process.env.SECRET_CODE — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#85 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEaHvItjFKlJjQwj_k5XpFE1gmrzqc19ks5rsq-jgaJpZM4BqUqZ> .

-- Thanks! *Manjunath Dharamadas (MG)* | Sr. Quality Engineer c: 309.530.1825 301 Congress Avenue, Suite 700, Austin, Texas 78701 Austin | Hoboken | Phoenix | London | Paris | Vannes *RetailMeNot is the first shopping app to earn the Good Housekeeping Seal!*

-- This e-mail, including attachments, contains confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. The reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.

[arterberry]

I am using nearly the same setup as @awesomebob, with one slight difference - I added the following:

const dotenv = require('dotenv');
require('dotenv').config();

To my nightwatch.conf.js. - with my .env setup the same way in the root of my Nightwatch project. Under my globals.js - I do not include a before function to support my dotenv. I simply include this:

MY_SECRET_CODE : process.env.SECRET_CODE

As for loading different variables for different environments, you will need to load all of your conditions under one .env file and then parse the data accordingly.

[alex-chen-bridg]

`var self = module.exports = {
environment: Math.round(1000)==1000?true:false,
parseArgumentsAndGetEnv:function(env){

    for(var i = 0; i < env.length; i++){
        if(env[i] == "qa"){
            console.log("what the heck the env should be defined " + process.env.ADMIN_PASS)
            self.adminPassword=process.env.ADMIN_PASS
        }

    }
},
before: function (done) {
	this.parseArgumentsAndGetEnv(process.argv)
	done()
},
beforeEach:function(done){
	done()
},
afterEach:function(done){
	client.end()
	done()
},
waitForConditionTimeout:10000

}`

And then using adminPassword in a test:
Given("an administrator has logged in", function (){
console.log(JSON.stringify(client.globals.adminPassword) + " testEnvironment ")

gives me undefined testEnvironment