I'm attempting to execute a TestCafe suite on locally installed Safari. I have previously executed the tests on chrome, chrome:headless, firefox, and firefox:headless. When running the command testcafe --list-browsers to retrieve my list of installed browsers, I receive the following:
testcafe --list-browsers
Using locally installed version of TestCafe.
firefox
chrome
safari
When I execute a simple test via command line, testcafe safari path/to/tests/, the Safari browser will launch, but no navigation takes place. I remain on the launch window (showing my favorites and recently visited pages).
When the same command is executed for a different browser (say, testcafe chrome path/to/tests/), the tests are executed in the local browser.
Am I missing something that is required to get Safari up and running with TestCafe? I'm using TestCafe version 1.6.1. I'm not seeing any additional setup mentioned on the TestCafe documentation...
I was able to resolve this issue by disabling all uses of TestCafe Browser Tools in System Preferences -> Security & Privacy -> Privacy -> Automation. On my subsequent execution, I was prompted to allow TestCafe Browser Tools for Safari. After accepting the prompt, the tests ran as expected.
I also had deleted my node_modules directory and reinstalled dependencies, although I'm skeptical if that helped.
Related
When I run tests with TestCafe Studio, I will often times get a browser disconnected error, even though the browser is not closed, and seems to be running. Has anyone seen a fix for this.
I am running in a Linux AWS environment, using chrome.
I am running some Testcafe e2e test on Chromium with concurrency = 4. The issue comes that all 4 browsers that testcafe opens are overlapped and the ones in the background dont run any test and freezes forever.
One of the concurrency that is on top of all 4 browsers will execute all the test and the other 3 concurrences will try to run 3 different test-fixtures without executing or starting any of the test.
I am running my test like
"testcafe \"chromium --disable-background-timer-throttling '--window-size=1200,700'\" src/tests -c 4 -reporter spec"
I have been checking that chrome can disable background browsers if --disable-background-timer-throttling is not disabled. Still having the same issue. Here is a discussion in the old Testcafe forum about this issue related with chrome https://github.com/DevExpress/testcafe/issues/2939 .
Any idea why Chromium is not executing my test in the background?
I found out that a workaround is to run the chromium browser in a headless mode. This will prevent the background windows to not be working.
I am trying to inspect the page during an integration test, and so I have a test which I added a breakpoint in-- Once chrome launches and the test begins, the breakpoint hits, and the browser is idle.. As soon as I open the web inspector, chrome quits with the error:
Selenium::WebDriver::Error::WebDriverError:
disconnected: received Inspector.detached event
I am using Chrome version 37.0.2062.124, and ChromeDriver version 2.10.267517
This is intended. This is because the ChromeDriver uses the DevTools API to interact with Chrome.
The DevTools within Chrome has one major disadvantage and that is it only allows one debugger (whatever that might be, whether it's you or the driver itself) attached to it. Thus, once you open it, ChromeDriver cannot use it.
This is a limitation of Chrome -> the best you can do is get your test to a point where it fails, have your test close it's session but leave the browser open. Thus you have quit your test but effectively left your browser in the state of which the test failed.
This is about chrome issue(https://bugs.chromium.org/p/chromedriver/issues/detail?id=1194).
When you are running selenium program, you cannot press F12 to open dev tools manually, or it'll throw this exception sometimes.
According to the issue list, it looks like fixed, but I still meet this bug in ChromeDriver 2.29
The same problem you can visit.
Is there a way to use phantomjs to drive my firefox/chrome browser?
We have a bunch of casperjs tests, that I would like to run directly in the browser for debugging ( or just pure interrest ).
I seem to recall that a long time ago, before phantomjs became pure headless, I could do this by making it run on X instead of xvfb and removing/uncommenting the phantom.exit() line.
PhantomJs IS a browser, so the answer is no. You may want to look into Karma however.
You just use a config file which allows you to provide a browser to run your tests in:
Chrome
ChromeCanary
Firefox
Opera
Safari (only Mac)
PhantomJS
IE & Edge (only Windows)
SauseLabs, BrowserStack Electron, & more
Still, your tests will need to be written in QUnit, Jasmine, Mocha, ... which can be too much work to port from CasperJs.
I have a problem with Selenium under Jenkins 1.446 together with Xvfb: It looks like firefox is started correctly because I let my failing tests record screenshots. These screenshots all show the same failing page, which in my case is the starting page where the tests should begin. So I gues the selenium WebDriver commands do not arrive. What could be the reason? By the way, the tests are running perfectly on my local machine.
I'm using Firefox 9.0.1 with no specific test profile and no AddOns, Ubuntu 10.04, Senlenium 2.16.1
Log entry: com.thoughtworks.selenium.SeleniumException: Timed out waiting for action to finish
Thanks!
EDIT: Issue seems to be fixed by a system reboot ...
I experienced a very similar issue with FF9.0.1 and Selenium 2.16.1 running through JUnit launched by Maven SureFire plugin run by Jenkins on a WinXP node.
2.17.0 fixed the issue for me. Try updating to the latest Selenium.
Through RDP, I was able to watch the tests running. The tests appeared to be partially blocked by a prompt from Firefox asking about collecting anonymous usage statistics. Manually answering the prompt would allow the test to continue but because Selenium creates a new profile each time by default, the prompt would return on the next browser launch. Running the tests locally with a pre-configured FF profile allowed me to persist that the prompt had been answered. This isn't possible on my XP node because the tests are running as 'System'.
Selenium/WebDriver would normally take care of this for you by marking the prompt as already answered in a temporary FF profile configuration but a bug was causing the value to be set to the wrong value. You can inject a profile configuration to the Selenium FirefoxDriver driver to pragmatically configure stuff like this prompt but the bug appeared to prevent this as well. This has been resolved in Selenium 2.17.0 (http://selenium.googlecode.com/svn/trunk/java/CHANGELOG see 2.17.0 WebDriver bug fixes).