Our Selenium tests were developed in C# and were running just fine for months but recently we noticed that a number of tests started failing when executed with Firefox WebDriver.
After investigating the test results and executing tests locally we noticed that from time to time clicks on random elements are executed (we can tell because the visual state of the button or the link changes to what looks like a clicked element)
Browser console does not indicated any errors. WebDriver logs show that click was executed.
Will be grateful for any help.
Edit:
Version of Selenium WebDriver - 2.53.0
Versions of Firefox - (tried few) 33.0.1, 43.0.1, 45.0, 46.0.1
Firefox scale 100%
tried with native events on and off
tried with additional implicit waiting before click
You question is not very specific, so I'll try to offer possible ways you can choose to resolving it.
You didn't indicate which driver and browser versions you used. If you didn't observe failures for months ant suddenly they appeared, my first guess would be that FF version you use on test machine(s) got updated (or driver version in tests was changed), and new combination can work differently. I had situation like this when tests behavior changed, updating driver version helped.
Another option would be to try and see which webelements get misclicked more often than others and insert instructions that check if they are displayed before executing actual click.
Also, try to do step-by-step debugging (if you haven't already) and see if you observe wrong clicks then
One thing we've seen in our testing is that if we're clicking around on the VM while a Selenium test is running on our VM, it can actually prevent clicks from going off.
But another thing we've encountered is that the clicks are often not working where they should be, so you can counter this by using JavaScript clicks instead of Selenium.
For elements that fail regularly, switch the element.Click() to a method utilizing the code below:
IJavaScriptExecutor executor = driver as IJavaScriptExecutor;
executor.ExecuteScript("arguments[0].click();", ElementToClick)
So the problem was that click does not work even when clicking manually so we'll be investigating in that direction.
Related
Google chrome automatically updated to Version 78.0.3904.87 yesterday and i now seem to have a problem with Selenium Webdriver.
When i run my tests in Visual Studio, the click events seem to occur but the expected result on screen does not happen e.g. clicking a link passes through the code (link.Click) successfully with no failure but the link does not get clicked on screen.
When i run the same test in Debug mode and Step Into each section of code it works fine, its as if selenium is running too fast for the browser (i have an implicit wait built in but its irrelevant, the element is there its just not clicking properly). I'm also finding things like sendKeys does not populate the field though it passes through the code successfully, again fine when stepping into it in Debug mode.
I've tried updating my Chromedriver to the version for V78 but this has made no difference
Similar problem here but my issue is not restricted to pdfs only
Chromedriver 78 cant find element in pdf
My team is running into the same issue. The issue seems to be the time between our WebDriverWaits and our Clicks -- the waits seem to be passing through instantaneously in cases they should not and then any Click element call (or action) hovers over what we want to click on but doesn't actually click.
I finally got to the bottom of this with our setup and it turned out to be the --enable-automation flag that seemed to be causing page flickering on page load.
After adding excludeSwitches: ['enable-automation'] to my config it has resolved the issue.
I want to test reactJS App with coded UI and play it back with Chrome browser. I'm recording my actions on IE, I have all selenium components and browser drivers installed, my chrome version is latest(tried older versions too). Scenario of my test is to type both login and password, log in then log out. So when i run my test on IE everything works perfectly. But if i run it on Chrome it types everything logs in, so when its on the main page with loads of components it wouldn't find log out button, saying it couldn't find controls with given info(tags, ids, classes). But when i inspect element with the info from test it matches perfectly.
Never mind folks, Solved the issue. Turns out Chrome doesn't wait for all components to load unlike IE. So as long as it clicked on login button it was going to search for that component not even waiting for page to load. So I just set some conditions telling to wait until everything loaded then try to look for components.
I am looking for a way to run selenium tests with a chrome driver, in the background. With the background I mean as in, not the foreground focussed window. I can actually do this, but as soon as actions like opening a new tab or switching between windows (so basically switching window handles) happen in the chrome driver, the browser window gets pushed to the foreground.
So my question is, how can I prevent this from happening without running the test headless?
Any suggestions are appreciated, open for discussion.
EDIT
As a somewhat temporary solution I came up with the following.
Using the Windows 10 Virtual Desktops feature, I run the test and thus the chrome browser window in a seperate virual desktop.
I then switch back to my main virtual desktop to continue with other tasks.
This prevents the chrome browser window from being forced to the foreground.
Note that this still makes a flashing chrome icon appear in the taskbar when any of the actions described above appear.
Still looking for a more solid solution, so any suggestions are still appreaciated.
To hopefully open new perspectives and discussion points, and ultimately a solution, I will provide some more detailed info of what my code is doing.
I have 5 chrome webdrivers, and each of these webdrivers contains 6 tabs (WindowHandles).
The idea is that a certain process has to be repeated continuously on each tab. So we loop over each webdriver, and within that webdriver over each tab and set this tab as the webdrivers current WindowHandle. This makes the chrome window visibly switch to the assigned tab.
After that switch has taken place, so basic selenium automation is performed on the content of the tab, after wich we repeat the whole process.
The actual issue seems to take place when a chrome webdriver switches to a new tab (WindowHandle), at this moment the chrome window containing the tab is pushed to the foreground and steals focus. Note that this does not always takes place, often it can switch tabs without any issues. So it is unclear wether there is another factor which would cause the window to steal focus.
EDIT 2
After doing the following:
I overloaded the selenium method which is used to switch between tabs (WindowHandles), and called SetWindoPos each time. Unfortunately this did not solve this issue either. I will try to look deeper into what might be causing this and will report back. – S. Van den Wyngaert
I went out for a few hours while running the tests, and came back to see that surprisingly I was still on my main Virtual Desktop (win10 feature). This means that the issue didn't occur during the time I was gone. I started working again, opened a chrome window and noticed that shortly after I did this, focus was stolen by one of the chrome driver's windows again.
What I conclude from this is that the issue only occurs when another chrome window (not opened by a chrome driver from code) is opened.
I will keep investigating and will report back with updates.
After investigating this behavior for a few more hours I noticed that when another chrome window is open, as long as this has focus, the issue doesn't take place. So to quickly summarize this:
The issue doesn't take place when:
No other chrome windows (not selenium driven) are opened or minimised
Another chrome window (not selenium driven) is opened and has focus
Another application running fullscreen mode has focus
The issue does take place when:
Another chrome window (not selenium driven) is opened and has no focus
Note that when I talk about another chrome window I specificly mean a chrome window that is not driven by selenium, so a regular chrome window opened by the user.
Easiest way would be to run a local selenium grid. Start your node(s) as a windows service. This way the test will run in the background, without being headless.
Another good option to scale your solution, and if your machine has the capacity to run docker, is to use
zalenium
It's a docker based, auto scaling, selenium-grid solution that works pretty quick out of the box.
You can watch your tests live via the management pages, watch a recording after the fact, pause/debug with live interaction via VNC. Also something to be said for not having the worry about changing browser versions.
Last time i used it, it had the odd bug and throws an end of stream error every now and then - but that was a good year ago.
i am automating using selenium webdriver and C#. Is there a way to capture all urls that my browser navigates to while my Selenium automation tests run using an external tool such as Fiddler core / wireshark. I mean while my tests continue to run, I would like some of these tools to capture my urls parallely so that incase my tests fail, i could investigate further by using the final few urls(from the point of failure) to debug the issue.
Is this really possible. Do I need to use a separate thread to one of these tools(Fiddler/wireshark/any other tool) to capture the url?
Can this really be done
There are a few options.
Start wireshark (or fiddler) before your Selenium test kicks off. You can do this with a batch file that gets executed in your test setup.
You can utilize a browser plugin for fiddler. IE has one, I'm not sure if there is a comparible plugin for all browsers though. Then you can get Selenium to activate this through the browser...assuming fiddler keeps in the browser window and not open a separate non-browser window that Selenium can't see.UPDATE: Fiddler plugins don't stay in the browser window so this option won't work.
Write some wrapper code that does a driver.Url and stores it into a list. This wrapper code would check to see if the driver.Url is different from the last stored entry in the object and if it is different then it would add it to the list.
All have pros and cons. 3 would give you the most control as your test itself would gather the URL's and maintain a list in code that you can do what you want with. 1 of course would give you the most robust details, depending on how you setup wireshark, and you can profile the entire machine and network experience. 2 is a middle ground where your test still drives it, but the results are separate...but being part of the browser you would have to avoid cleanup after your tests...if you have more tests than one execute at a time this could cause alot of problems...
I am testing a complex web application using a test framework comprised of C#, Nunit 2.5.10 and Selenium RC 2.24.1 (Switching to WebDriver is not an option unfortunately).
We recently overhauled our application UI/UX, so we have been systematically updating our tests to fit the new version.
Everything has been pretty smooth until we ran into an issue where our browser seems to randomly crash when running certain tests. We use Firefox(Chrome Driver) for testing, but have various versions installed on our test clients from 3.6 to 15.01. The issue seems to be consistently reproducible on all browser versions running on Windows 7 and Windows Server 2008 R2.
When the browser crashes it leaves behind a dialog which remains even after we run our clean up method which kills any open browser sessions in preparation for the next tests. Because this dialog sticks around, it keeps an RC server session alive which causes the next set of tests to hang.
I traced the tests down to the specific actions which are causing the crash, and it seems to always be a click event, but on various buttons within the application, and not always the same one. The buttons have nothing in common except that they all trigger a javascript postback. I was also able to trace one crash to a postback event triggered by a drop down box selection.
Our test framework is fairly complex and we have thousands of tests, so we have resorted to commenting the crashing tests just to keep the rest of the suite running.
We have been unable to simulate the crash with manual testing, even when following the exact path taken by the selenium test.
Any thoughts on what might be causing this, or ways to troubleshoot it would be appreciated.
I've had issues with intermittent failure of Selenium tests caused by the real time protection on Microsoft Security Essentials. For me unchecking Turn on real-time protection in Settings | Real-time protection while I was running tests fixed the issue. Try disabling your anti virus while running tests and see if that solves your problem. Apparently the actions taken by Selenium can be interpreted as virus activity.