I'm starting out with e2e testing with Protractor.
To test some pages I first need to login. Now I have this part for entering the password:
var passInput = element(by.id('Passwd'));
passInput.sendKeys('test');
Now when I replace the 'test' with my actual password, and I accidentally commit my changes to git, my password is exposed.
I can't work with a dummy account because we use Google Auth. It needs to be an actual account.
Is this the intended way to go in Protractor? Is there a work-around?
To continue on @Sudharsan-Selvarj's answer.
You should create 2 files:
environment.json
and environment.dist.json
. Now first of all, add environment.json
to your .gitignore
.
environment.json
{
"password": "correcthorsebatterystaple",
"username": "stijnisdebeste",
"server": "https://stijn.development.server"
}
environment.dist.json
{
"password": "-- ADD PASSWORD HERE --",
"username": "-- ADD USERNAME HERE --",
"server": "-- ADD SERVER HERE --"
}
Now in your protractor you can use the environment-variables that will never be pushed to the GIT-server. Every developer now has to use his own credentials etc.
If you find a better solution, please let me know :)
edit:
Are you certain that you need e2e-tests? Or could you simply use integration tests? Because we've abandoned e2e-tests in favour of integration-tests; And as this google blogpost states:
- Write many, many unit-tests. These mock out every dependency to the unit you are testing.
- Write many integration-tests. Integration tests actually use all classes, but mock the backend. Since the DOM should simply use getters/setters of your controller, it should be easy to test without even thinking about reading the DOM in your tests.
- Write some e2e tests. e2e are expensive tests, they take long to run and are harder to control. The only reason I've seen to actual e2e is to check browser compatibility of different HTML-5 implementations.
You can create seperate json file in your local machine and save the username and password in that file.Dont add the json file for git tracking so that it will not be pushed to origin whenever you commit your code.during execution pull the scripts from origin and start executing your scripts.
Unless you could really mock the whole Google Auth (and any directly associated) API, you don't have a better way of doing that other than using a "real" account dedicated for testing. Then your application needs to know not to show any production data to this user. Google unfortunately does not offer testing accounts. However, sooner or later, you might still run into issues with rate limits. I'd love to offer better solution, but Protractor itself doesn't offer any tools in this case.