I need to pass the credentials in command running a script.
For now, I am using in protractor file following part:
onPrepare: function () {
jasmine.getEnv().addReporter(new SpecReporter({
spec: {
displayStacktrace: true
}
}));
if (browser.params.Url == 'http://devel/') {
browser.params.webmaster='abc';
browser.params.webmaspass='foo';
}
//(other environments)
else {
console.log('-------------error during log in');
}*/
}
and it was working fine, but I need to change it - I can't pass credentials in this way. I thought about changing it to:
if (browser.params.Url == 'http://devel/') {
browser.params.webmaster='';
browser.params.webmaspass='';
}
and run the script using
npm run dev-script --browser.params.Url='http://devel/' --browser.params.webmaster='abc' --browser.params.webmaspass='foo'
where package.json I have:
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"dev-script": "protractor --params.Url=http://devel/ --browser.params.webmaster='' --browser.params.webmaspass=''"
},
(or any variation) But it fails - I can't update params during running script, I need to write down the credentials in the code (which I find a little unsafe)
I found issues like Protractor needs password for login => insecure? but it about Google Auth problems
Any idea?
You need to remove the variable assignment in the onPrepare. You are overwriting what you are passing in from the command line by setting it to an empty string.
When you pass them in from the command line they will be availble on the params object. There is no need to set them again in your onPrepare. Add a console.log() in your onPrepare and you will see.
Run it from the command line like this: protractor conf.js --params.webmaster=abc --params.webmaspass=foo --params.url=http://devel/
Again, if you log them in your onPrepare you will see that it is working. The way you currently have it you are just overwriting the values you are passing in through the command line.
onPrepare: function () {
jasmine.getEnv().addReporter(new SpecReporter({
spec: {
displayStacktrace: true
}
}));
if (browser.params.Url == 'http://devel/') {
consoel.log(browser.params.webmaster) //should be abc
console.log(browser.params.webmaspass) //should be foo
}
//(other environments)
else {
console.log('-------------error during log in');
}*/
}
Another way you can do this is to set some environment variables before your test run and then you can access them in your scripts by using process.env.envVariableName or ${envVariableName}. Both ways will work.
set DEVEL_WEBMASTER=abc
set DEVEL_WEBMASPASS=foo
onPrepare: function () {
jasmine.getEnv().addReporter(new SpecReporter({
spec: {
displayStacktrace: true
}
}));
if (browser.params.Url == 'http://devel/') {
browser.params.webmaster=process.env.DEVEL_WEBMASTER;
browser.params.webmaspass=process.env.DEVEL_WEBMASPASS;
}
//(other environments)
else {
console.log('-------------error during log in');
}*/
}
Just remember that if you use this method you would have to set the variables for each session. If you are planning to automate these tests using a CI environment you can just add them there as secret variables (if you have that option) and they will always be there ready and waiting. There will be no need to set them manually during each build.
What I did it here was create the scripts in my package.json:
scripts: {
"automation-test": "concurrently --raw --kill-others \"./node_modules/.bin/webdriver-manager start\" \"sleep 5 && ./node_modules/.bin/protractor configuration/protractor.config.js\"",
"automation:pending": "TAGS=#pending npm run automation-test"
}
And in my protractor.conf.js I just assign the value to a variable so I can use in my config. Like this:
let tags = process.env.TAGS;
Then the command that I run is just this:
npm run automation:pending
but I could pass the TAGS like this as well:
npm run automation-test TAGS=#pending
I have not seen the configuration file on the parameters of the command line. you must specify the configuration file:
example: protractor config.js --params ......
Do this in your script file: i have added a config file after the command protractor
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"dev-script": "protractor config.js --params.Url=http://devel/ --browser.params.webmaster='' --browser.params.webmaspass=''"
},
Related
I want Cypress to execute custom scripts before and after running the specs suite.
The before:run and after:run APIs look perfect for that.
But the same snippet that works perfectly in before:run doesn’t seem to work in after:run:
module.exports = {
e2e: {
setupNodeEvents(on, config) {
on("before:run", details => {
console.log("Before run:")
exec("npm run cal", {}, handleExecOutput)
})
on("after:run", results => {
console.log("After run:")
exec("npm run cal", {}, handleExecOutput)
})
},
},
};
The cal script is defined in package.json as simply calling the native cal command, as a minimal test.
This is logging "Before run" and the calendar (not exactly together) before running the specs, and only "After run" after running the specs. However, if I change npm run cal to simply cal, the command is executed in both cases.
I’ve tried it with and without promises, with yarn and npm, always the same result. What am I missing?
When running Cypress headlessly, I can see console.log output from the frontend code under test by using the DEBUG environment variable, like:
DEBUG='cypress:launcher' npx cypress run --browser chrome
However, I haven't found any similar way to see the output of cy.log from the Cypress test code when running headlessly. Even with DEBUG='cypress:*' I don't see them - they only seem to be visible in the interactive interface. It feels like there must be some way to see the cy.log output headlessly - can someone help with that?
The first step is to add a new task in your Cypress config file so that you can run console.log from Node:
import { defineConfig } from "cypress";
export default defineConfig({
e2e: {
setupNodeEvents(on, config) {
on("task", {
log(args) {
console.log(...args);
return null;
}
});
},
},
});
Then, you can override cy.log so that it calls this task whenever you run the command in headless mode, and console.log when you're running in headed mode. You can do this by adding the following to your commands file:
Cypress.Commands.overwrite("log", function(log, ...args) {
if (Cypress.browser.isHeadless) {
return cy.task("log", args, { log: false }).then(() => {
return log(...args);
});
} else {
console.log(...args);
return log(...args);
}
});
I have a Nightwatch.js test suite running. When it completes, I've configured the output directory using the output_folder setting. It produces JUnit XML files in that directory correctly. I have an existing automation tool which scans the directory for JUnit test XML files and reports on them. Unfortunately it only matches files in the directory with a naming scheme: TEST-.xml. Let's assume that I can't change the matching rules on my automation tool. I'm looking for a way to add "TEST-" as a prefix to my tests. Ideally I can do this by configuring Nightwatch. Does Nightwatch support this configuration? I can't find any such options.
I ended up changing my test scripts in package.json so that they did a rename after the test was run. Here is what they were before:
{
// ...
"scripts": {
"integ-tests": "<some nightwatch command>"
}
// ...
}
Here is what they were after:
{
// ...
"scripts": {
"rename-integ-tests": "node -e \"require('fs').readdir('<my test directory>', (err, files) => { files.forEach(file => { if(file.endsWith('.xml') && ! file.startsWith('TEST-')) { fs.rename('<my test directory>' + file, '<my test directory>/TEST-' + file, function(err) { if (err) console.log(err); console.log('Renamed Smoke Test: ' + file + ' to TEST-' + file) }) } }); });\"",
"private-integ-tests": "<some nightwatch command>",
"integ-tests": "npm run private-integ-tests && npm run rename-integ-tests"
}
// ...
}
I am trying to run mocha with gulp with the configuration existed before.
moch.opts has the following line.
--timeout 999999
--ui tdd
--full-trace
--recursive
--compilers js:babel-register
how to add them here :
gulp.task('test', function() {
return gulp.src('sampleTest/*.js', { read: false })
.pipe(mocha());
});
I believe you can either create properties on the options object passed to gulp-mocha or you can just have it read the options file. In my case, I didn't want to duplicate things like --recursive or --require test/_init.js, but I did want to override the reporter, so I use the code shown below:
gulp.task('test', ['compile'], function() {
return gulp.src([], { read: false })
.pipe(mocha({
opts: 'test/mocha.opts',
reporter: 'min'
}))
.on('error', gutil.log);
});
You may want to modify this so that it doesn't assume the default path to test files (e.g. test/*.js), but in my simple case I didn't even need to pass a path to mocha. I'm just using gulp to trigger it (as if I had run on the command line something like mocha --opts test/mocha.opts --reporter min)
Options are passed directly to the mocha binary, so you can use any its command-line options in a camelCased form. this is the document link
gulp.task('test', ['compile'], function() {
return gulp.src([], { read: false })
.pipe(mocha({
timeout: 999999,
fullTrace: true,
reporter: 'min'
}))
.on('error', gutil.log);
});
add the setTimeout call after the mocha call
.pipe(mocha(),setTimeout(function() {
}, 999999))
I would like to pass an argument to grunt-shell like it is defined in the documentation:
module.exports = function(grunt) {
// Configure Grunt
grunt.initConfig({
shell: {
hello: {
command: function (greeting) {
return 'echo ' + greeting;
},
options: {
stdout: true
}
}
}
});
grunt.loadNpmTasks('grunt-shell');
grunt.registerTask('d', 'shell:hello');
When I execute it without argument it's working but when I try to put an argument I got an error:
Julio:Server julio$ grunt d
Running "shell:hello" (shell) task
undefined
Done, without errors.
Julio:Server julio$ grunt d:me
Warning: Task "me" not found. Use --force to continue.
Aborted due to warnings.
Where is my misunderstanding?
Thank you
Your problem is the alias, aliases don't work like you think.
If you use
grunt shell:hello:me
Then it'll work the way you expect it to.
Since aliases can be a list of zero or more tasks, it wouldn't make sense for them to pass parameters to other classes. If you want to alias it so badly, then the best you can hope for is creating another task to do the aliasing, rather than a real alias.
grunt.registerTask('d', function (greeting) {
grunt.task.run('shell:hello:' + greeting);
});
In that case then you would be able to do what you intended, using
grunt d:me