3

Basically, if the test cases are ran on Chrome, FF or Edge, they go through without a problem - and you can even use the browser after the tests.

With IE however, running it from a web driver basically makes the browser unstable. This is for both the framework and manual usage. The issue I am having is that some elements flicker when they have been selected. And unfortunately, I am trying to select an element deep inside a drop down table. Once it starts to flicker, and then executes the Click Element, it clicks behind the drop down, and thus accidentally clicking on a completely different element and stopping my tests.

Is there a way round this? I need to automate our tests on all 4 of the browsers.

Goralight
  • 2,067
  • 6
  • 25
  • 40
  • Give up IE for automated tests is the best option IMHO. The effort for automating IE is simply isn't worth it, since IE works differently under the hood and IEDriver is very unstable... – Moshisho Nov 22 '16 at 10:41
  • Is there seriously nothing I can do? Been bashing heads with it for the past day ... – Goralight Nov 22 '16 at 10:44
  • You say your code works for 3 major browsers but for IE it fails. Do you really want to put in your code ugly patches for IE that can harm the rest of your tests? I'd recommend rethink the ROI for IE automated tests, or perhaps use another tool: http://stackoverflow.com/questions/3841371/test-automation-for-internet-explorer – Moshisho Nov 22 '16 at 10:48
  • Youre right, the ROI is not worth it. I have already broken one test case trying to make it work with IE for the other browsers. I think im just going to have to use a seperate tool just for IE after im done with the other tests. Thanks Moshisho! – Goralight Nov 22 '16 at 10:54

4 Answers4

2

So I had the same/similar issue when I tried to automate my tests using Robot in IE11. In my case, once the elements start flickering the test doesn't even proceed further. The browser just hangs without any interaction. The workaround I found was, to use "Press Key" keyword instead of "Click Element" and given an enter key. This worked fine for me and I was able to complete my tests. Ofcourse I had to add two two test cases one for IE and one for other browsers but it did work!!

Below is the example test case:

Click Add - IE                
    # Click Element    ${I_Add}    --> This is for the other browsers
    Focus    ${I_Add}              -->
    Press Key    ${I_Add}    \\13  --> These are for IE

If you have any further clarifications please do ask me

Vaish
  • 37
  • 5
1

IMHO, InternetExplorerDriver isn't stable enough and isn't worth the ROI for automated tests, especially in your case where 3 major browsers work with your code, and IE will require ugly patches that can harm the rest of the tests. To quote from InternetExplorerDriver:

Cons

  • Obviously the InternetExplorerDriver will only work on Windows!
  • Comparatively slow (My addition - See Dave Haeffner's great benchmark)

Special Configurations:

On IE 7 or higher on Windows Vista or Windows 7, you must set the Protected Mode settings for each zone to be the same value. ...Additionally, "Enhanced Protected Mode" must be disabled for IE 10 and higher ... For IE 11 only, you will need to set a registry entry...

How Javascript Events are implemented:

As the InternetExplorerDriver is Windows-only, it attempts to use so-called "native", or OS-level events to perform mouse and keyboard operations in the browser. This is in contrast to using simulated JavaScript events for the same operations. ... However, there are currently some issues with mouse events when the IE browser window does not have focus, and when attempting to hover over elements.

And the list goes on...

Moshisho
  • 2,781
  • 1
  • 23
  • 39
  • I can't in good conscience support this answer. The characterization of implementing proper synchronization methods or waits for the DOM being automated to be in a known state as "ugly patches" that "harm... tests" is both misleading and irresponsible. – JimEvans Nov 22 '16 at 14:26
  • That's not what I said... and that's not what the question is about... the problem is with stability of tests on IE, on other browsers it's working, so I guess the implementation is not the problem. Moreover, see the quotes (not my opinion...) and the benchmark... – Moshisho Nov 22 '16 at 14:48
  • 1
    Its is nothing to do with waits or any other bad practise. I am simply trying to get around the poor performing IE Web Driver - I shouldn't need to make IE run special little tests, whereas the others don't. – Goralight Nov 23 '16 at 09:11
1

Did you try using the requireWindowFocus capability for use with IE? There are perfectly valid technical reasons for why the driver behaves as it does. I would encourage anyone interested in why to read a blog post dedicated to discussing the issue.

JimEvans
  • 27,201
  • 7
  • 83
  • 108
0

It may or may not work for you; but still take a look at -

  1. Add your application URL as trusted site.
  2. Make sure "Enable Protected Mode" is either ON or OFF for all 4 zones (Internet, Local Intranet, Trusted Sites & Restricted sites.
  3. Turn Off pop up blocker.
  4. Turn off SmartScreen filter.
Hemant Kulkarni
  • 193
  • 4