In a previous post, we talked about the value of using modules created by the community to enhance the functionality of Protractor, using Jasmine Data Provider as an example. While user generated plugins are awesome, it’s important not to forget how robust Protractor is on its own. If you’re willing to read the API docs on it and do a little experimenting, you’ll find that Protractor has a number of built in features that can add yet another facet to your automation stack. One of those features is configuration parameters.
Why Parameters?
Protractor configuration parameters are…well, parameters! They are key-value pairs that can be defined within your configuration file and are then injected into your spec files where you would normally have hard coded values. More importantly, their values can be defined at the command line right before running. All of this is useful for a few reasons:
Keeps your code DRY
- – If you know you’re going to be using the same values in multiple spec files (i.e login email and password), parameters are great for removing unnecessary repetition.
Adds flexibility
- – Being able to change parameter values at runtime makes it easier to run the same tests with different data (think testing users with different admin privileges) all while never touching your code!
Increases security
- – Having passwords hard coded in your spec files sucks. Parameters give you the ability to keep them out and instead provide them at run time.
If all of this sounds great to you, then stay tuned! This tutorial will show you how easy it is to start using parameters in your own automation stack. Let’s do it.
Adding Parameters
An example used above was adding parameters for email and password values. These are good examples because more often than not in end-to-end testing, you’re going to be logging in a bunch. We’ll use these values below in our tutorial. To get parameters working properly, code needs to be added in two files: the Protractor config file, and the spec file you want to use the parameter in.
To start, add this code to your conf.js file:
module.exports = {
params: {
login: {
email: 'default',
password: 'default'
}
},
// * other config options *
}
Here, the parameters are defined so that the spec file will know what values to inject when referenced. In the example above, ‘default’ is the supplied value for each, but you can pass any string to it since that value can be changed at runtime. If you’d like to have the option to run your tests without parameter flags in the command line (which we’ll get to later in the tutorial) you can change them to values your application actually uses.
Next, you can reference these parameters in your spec file with code that looks like this:
describe('describe some test', function() {
it('describe some step', function() {
$('.email').sendKeys(browser.params.login.email);
$('.password').sendKeys(browser.params.login.password);
});
});
Now, instead of using hard coded values, Protractor will use what is provided in the config file unless the user changes those values via the command line when running the spec file. To do this, add these flags to your protractor call:
protractor conf.js --parameters.login.email=example@gmail.com --parameters.login.password=foobar
And that’s it! Wherever you reference those parameters in your spec files, these new values will be filled in.
Conclusion
Parameters are just one of the many Config options Protractor provides right out of the box. For a full list you can check out Protractor’s example configuration file on their GitHub. Use any cool config options in your own test suite? Let us know in the comments!
