Feature Request
Flags are not passed to the opening browser.
The browser on which the test will run, should receive the flags
I'm trying to use Service Workers in the page, but they require localhost or https and _testcafe_ is currently redirecting the browser to a server of itself (therefore, not https neither localhost). I could send a couple flags to the browser and it would not be a problem:
testcafe chrome --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=* tests/
Hi! While it doesn't work via Command Line Interface you can use Programming Interface as a workaround. You can see how to specify the Path to the Browser Executable with Command Line Parameters here
Interesting, thanks!
But in this case, I must specify both path and cmd...and defining the path is not an easy task to do if I want it to run it in many different machines (including travis, for example).
Is there a way I could say "chrome" and the flags(cmd), perhaps?
Yes, you can use the getBrowserInfo function from our TestCafe Browser Tools package. For example:
const testcafeBrowserTools = require('testcafe-browser-tools');
const createTestCafe = require('testcafe');
var chromeInfo = null;
testcafeBrowserTools
.getBrowserInfo('chrome')
.then(res => {
chromeInfo = res;
chromeInfo.cmd = `${chromeInfo.cmd} --incognito`; // add your flags here
})
.then(() => createTestCafe('localhost', 1337, 1338))
.then(testcafe => {
return testcafe
.createRunner()
.src('your-test.js')
.browsers(chromeInfo)
.run();
});
I believe it's worth implementing on our side: add ability to specify browser parameters for aliases. But command line syntax requires some bikeshedding.
Maybe something like:
testcafe "chrome --ignore-certificate-errors",firefox tests/
Thanks @AlexanderMoskovkin, will try that, then.
@inikulin I think that would be an amazing implementation (using quotes), this way we could even use two or more browsers, sending to each one, its own flags.
As for _my situation_, all I need is it to be opened in the browser as localhost. I noticed you start a server in my machine's IP in the given ports...do testcafe must open it as an IP address? I mean, localhost:port would work as well, and would allow people to even use their hosts file or rules for "localhost" special treatments (as in my case, from Service Workers spec).
As for my situation, all I need is it to be opened in the browser as localhost. I noticed you start a server in my machine's IP in the given ports...do testcafe must open it as an IP address? I mean, localhost:port would work as well, and would allow people to even use their hosts file or rules for "localhost" special treatments (as in my case, from Service Workers spec).
You can specify localhost or your machine instead of IP address via --hostname command line option. Initially, we've used localhost as default hostname for TestCafe server, but it had some performance problems with SauceLabs tunnel (I can't find issue references at the moment, guys can you provide some insights here please cc @DevExpress/testcafe). So we decided to use NetBIOS name as a hostname, but it had problems with Edge browser: https://github.com/DevExpress/testcafe/issues/575 So we finally ended up using IP address as a solution that works properly with all platforms. Overall, if you're testing on local machine localhost should work just fine for you.
Thank you @inikulin , I'm using it and it is working. I believe I will manage to have it published pretty soon :)
Will keep you up to date to check on ways (still working on it) to test service workers.
I didn't find in the docs but after some digging of the source code, it seems that the following syntax is also supported:
await createTestCafe()
.src('file.ts')
.browsers('chrome --incognito --no-sandbox')
This thread has been automatically locked since it is closed and there has not been any recent activity. Please open a new issue for related bugs or feature requests. We recommend you ask TestCafe API, usage and configuration inquiries on StackOverflow.
Most helpful comment
I believe it's worth implementing on our side: add ability to specify browser parameters for aliases. But command line syntax requires some bikeshedding.
Maybe something like: