I'm running my DalekJS tests (0.0.8) successfully in PhantomJS and also in Chromium on a Linux system.
But i have a small problem with Chromium.
After running the tests the dalek process will not quit. I can only end it with Ctrl+C or by Closing Chrome manually.
I would like to implement an automatic testing system. Therefore it would be nice if the test process would quit like with phantom or with the saucelabs driver.
Is there something i can do about that?
Edit: From the verbose log i see that "dalek-browser-chrome: Shutting down ChromeDriver" is emitted. So the kill code somehow does not work on my Debian 7.
Thanks!
I helped myself with a quick and dirty fix.
It looks like the code does not recognize all chrome processes to kill. Many of the pids and processIDs that are checked are 'undefined'. Maybe it has to do with the fact that i use Chromium on my Debian 7.4 x86 system.
The dirty fix is to add the following code into the index.js of the dalek-browser-chrome module at line 599 in the function _checkProcesses() just under the comment "//kill leftover chrome browser processes":
if (process.platform != 'win32'){
cp.exec('pkill -f /usr/lib/chrom');
}
Of course this will kill all Chromium instances. Not only the ones spawned by DalekJS. But for my usecase this is sufficient for now.
Related
I am using a very complex setup to test various non-public webpages. I use jenkins to run the python-selenium tests within a dockerimage. That way, I am completely independent of the jenkins environment and can create my own environment. In this environment I have the following software installed:
Ubuntu 16.04.3
Firefox: Mozilla Firefox 57.0.1
geckodriver: 0.18.0
nosetests: 1.3.7
selenium: 3.8.0
When running the tests, which mostly succeed, I see in the geckodriver.log output messages like
(firefox:55): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
/usr/bin/dbus-launch terminated abnormally without any error message
My questions:
What does this message mean?
Could that be an indication of the reason why sometimes the tests are failing?
If so, how to fix it?
The error you are seeing is :
(firefox:55): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
/usr/bin/dbus-launch terminated abnormally without any error message
So it is clear Firefox attempts to connect to D-BUS daemon and fails as dbus-launch gets terminated abnormally.
dbus-launch
dbus-launch is basically the utility to start a message bus by firefox through a shell script. It would normally be called from a user's login scripts. dbus-launch launches a session bus instance and print the address and pid of that instance to standard output.
You can read more about dbus-launch from the Linux man page
Root Cause
This error can arise if you use su (root), sudo, suedit, gksu. The main reason is DBUS_SESSION_BUS_ADDRESS retains its value when you su instead of picking up the value in /root/.dbus/session-bus.
Here you will find a detailed discussion on GConf Error: No D-BUS daemon running?! How to reinstall or fix?.
Another possible reason may be the base Firefox Browser version may be an older version on which updates were taken to reach the current version.
Solution :
There are a couple of solutions available to address this ubuntu related issue as follows :
Before you start Firefox you have to type export $(dbus-launch)
However this may result into another error with NSS_USE_SHARED_DB. So you have to use export NSS_USE_SHARED_DB=ENABLED as well.
The most convenient way would be to put all the configuration with in .bashrc file :
export $(dbus-launch)
export NSS_USE_SHARED_DB=ENABLED
firefox &
This discussion speaks about the solution in details.
If dbus-launch is not installed on your system you have to install dbus-x11 package which contains the dbus-launch program.
An effective solution would be to uninstall the older base version of Firefox Browser and install a recent released GA version of Firefox Browser.
Best Approach
The issue with dbus-launch was addressed properly by both Ubuntu and Mozila. To overcome this error you need to follow the below mentioned steps :
Keep your Ubuntu os updated with the Latest Patch Releases and updates.
Always use the latest released version of Selenium-Python client, WebDriver variant e.g. GeckoDriver and Web Browser, e.g. Firefox Browser.
Clean and Build the Project Workspace afresh through your IDE before and after executing your Test Suite.
Clear the Browser Cache before and after the execution of your Tests.
If you have to uninstall any of the Web Client variants (e.g. Mozilla Firefox) you can use Revo Uninstallar with Moderate Memory Scan so that the stale registry settings are discarded.
Use CCleaner tool regularly to wipe away the OS chores including the stale rust_mozprofile directories.
What does this message mean?
DBus is a message bus system for interprocess commutation. There is an open geckodriver issue on a similar if not the same subject:
request to geckodriver fails with no meaningful log entry when there is no access to $HOME/.mozilla or $HOME/.cache
Could that be an indication of the reason why sometimes the tests are failing?
The warning should not really affect the tests but it's difficult to speculate about your intermittent test failures without seeing what is actually happening in your tests.
If so, how to fix it?
Here are some things to try:
upgrade geckodriver to the latest stable version (currently 0.19.1)
update Firefox to the latest nightly version (currently 58)
try this answer
try this answer
For me the solution was to install dbus-x11
apt install dbus-x11
I'm having troubles running Ruby/RSpec tests against Safari 11 when I'm trying to run tests via ssh manually or via Jenkins (where machine where Safari exists is remote slave).
When executing tests, I'm getting following error:
Selenium::WebDriver::Error::WebDriverError:
unable to connect to safaridriver 127.0.0.1:7050
What is weird is that I'm able to run tests when I'm logged to the Mac machine directly. This leads me to the conclusion that there could be some permission which, by default, disables execution from ssh session but not sure why?
Also, to my knowledge, Safari Driver is part of Safari 10+ and as such is not installed anymore as extension
Update: I've found out that safaridriver executable that should be spawned by tests cannot be spawned from some reason when I login via ssh.
Example:
/usr/bin/safaridriver -p 7050
It will just terminate with non-zero exit code while running same command directly on machine will run safaridriver in foreground. Since I expect Jenkins to be running test job on this machine, my idea to overcome this issue would be to launch safaridriver on this machine (by cron or launchctl) and then use this instance to connect to it with my tests. However, so far, I was not able to make my tests (Selenium/Capybara) re-use existing safaridriver instead of always trying to spawn new one on different port. Any idea on this would also be greatly appreciated.
This is my environment:
OS: MacOS Sierra 10.12.6
Browser: Safari 11.0.2
Thanks in advance
There is a possible workaround to do this. First you need to create a Automator Workflow or Apple Script that launches the SafariDriver
Then save this as a application. Let assume we name it SafariDriver7050.
Then from the SSH session you need to execute
open /Applications/SafariDriver7050.app
This will actually launch SafariDriver in the logged in session and it should work for you.
The caveat being shutting it down, you will need to first kill the SafariDriver7050 app and then you need to kill the safaridriver process. The order matters, else it will create a error dialog on UI
Edit-1:
As you suggested, it would be even easier to do this, when you wrap your test as a app and then it will be automatically be able to launch SafariDriver without any issues. The key to issue is using open command in a SSH session
Edit-2
Why does SafariDriver not work in SSH? Well if you look at the linux counterpart
In case of linux we can use the DISPLAY environment variable to launch an app in an existing display or we can use something like XVFB to launch the browser in a virtual display. That is the concept that most frameworks use in case of linux machines.
But Mac doesn't have such kind of feature, which is why this workaround is needed. Now why it doesn't have that, I am not sure. There may be some other workaround that I may not be aware of, so anyone who has valuable info, can help improve this part of the answer
For my case:
On OSX host side was created Automator app as described above and modified a little bit:
security unlock-keychain -p your_host_password /Users/$USER/Library/Keychains/login.keychain-db
safaridriver --enable
safaridriver -p 7050
On CCI/Jenkins side:
open /Applications/StartSafariDriver7050.app/
run pytest cmd
osascript -e 'quit app "StartSafariDriver7050"'
pkill safaridriver
In Python:
def safaridriver():
return webdriver.Safari(desired_capabilities=Caps.SAFARI, port=7050)
I started out trying to learn how to write automated tests for a small project but nothing was working right out of the box. After a couple hours of searching & experimenting I found the right configuration for my project & figured sharing it might help folks in the future.
Here's a small summary of the errors I encountered on this debugging journey:
Using Jasmine & WDIO, send_keys was crashing
It was a Firefox/geckodriver bug, or something like that
WDIO appeared to hang after switching from Firefox to Chrome
Chrome needed to be run in --no-sandbox mode, essentially
I figured my problem was probably stemming from having WDIO execute my tests on my local machine while Selenium was hammering on the browser in a Vagrant VM. So this will mainly be applicable for people using separate environments (vagrant->local, vagrant->vagrant, docker->local, etc) for WDIO & Selenium/Chromedriver. Here is a gist of the configuration file I ended up with.
I started with fanatique/vagrant-selenium-vm and modified it to use Chrome instead of Firefox because send_keys was broken with Firefox/geckodriver at the time of writing. After swapping out the packages, I'd start the tests with wdio but it would appear to hang. Turning on verbose logging showed it trying to start but failing with no explanation why.
[00:06:39] COMMAND POST "/wd/hub/session"
[00:06:39] DATA {"desiredCapabilities":{"javascriptEnabled":true,"locationContextEnabled":true,"handlesAlerts":true,"rotatable":true,"browserName":"chrome","loggingPrefs":{"browser":"ALL","driver":"ALL"},"requestOrigins":{"url":"http://webdriver.io","version":"4.6.2","name":"webdriverio"}}}
It took removing the & from the nohup java ... command in fanatique/vagrant-selenium-vm's setup.sh to see the logs from Selenium in real time, then I was able to see a "only local connections are allowed" message from chromedriver. That led me to a SO post that said to add --whitelisted-ips="" as an arg to chromedriver - but I was still getting the local connections error message. Chrome itself ended up needing a --no-sandbox flag - that allowed WDIO to connect to the chromedriver in Selenium and my tests ran from there.
I am having a really hard time figuring out as to why the selenium test cases are running slowly with phantomjs ghostdriver. When the developers run the test cases against the dev environment it runs faster(takes 1 hour to complete 5 test cases), but when ran from jenkins, it takes 4 hours.
I turned off the IPV6 on the dev machine, also tried switching to version 1.9.1, but still no improvement on the time taken.
Jenkins Machine
phantomJS: 1.9.2
Jenkins Server: RHEL 5.6 64 bit
JDK: 1.7
Developer Machine
OS: Windows 7 64 bit
JDK: 1.7
phantomJS: 1.9.2
Can someone please help?
Thanks in advance
Are you using driver.quit() or phantom.exit() after each test case as phantomJS process not get killed automatically. If no then it could be the reason of slowing down your test cases.
If your tests do not quit the drivers, your jenkins box will have a lot of open browsers in memory after a while.
For instance, every test that starts, then asserts false somewhere and dies, leaves an unclosed driver. These tend to build up after a while.
Depending on your testing framework.. there may be good solutions around it other than wrapping each test in their own try/catch blocks.
py.test has great fixture functionality. You can have a phantomjsdriver() fixture that opend the browser for each test, then after the test is done (safely, or aborting from a False assertion) it can finalize and close up the driver.
psudocode example: (py.test, python, selenium)
#pytest.fixture
def phantomdriver(request):
driver = webdriver.phantomJS()
def fin():
driver.close()
request.addfinalizer(fin)
In this situation, every test that uses this fixture, no mater how it exits, will end up calling the finilizer fin() to close it.
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).