For automation testing with Selenium, I found using the webdriver.keyboard.senkeys(elementCoordinates) seems like a more reliable way to locate and sendkeys to the element compared to webElement.sendKeys(). Basically, they should all be designed for the same function, but why one could work but sometimes the other doesn't work?
Related
I have a situation where the IDs of all elements are unique GUIDs, regenerated on each page load.
So I can't use IDs, although Selenium IDE defaults to IDs for obvious reasons.
My workaround is to record with Selenium IDE, then go back and manually edit the IDs to replace them with the right XPath, but this is really time-consuming.
Is there a way it can be set to use XPaths instead of IDs, by default?
Or is there another similar application/extension which can do this?
Selenium IDE/Katalon... recordings can be an OK starting point, depending on who you ask, but you need to go over them.
XPath expressions are specially tricky and often need to be worked on after a recording tool obtains them.
There is no way around this even if you can get the tool you are using to use xpath by default somehow.
I am trying to switch frames in MS Dynamics 365 system using Selenium WebDriver. I will explain one of the issues below. Here is the html element code:
element code here
Usually, i used to use id=contentIFrame0 or 1, and the frames were switching fine. The problem is, that MS Dynamics generates those iframes dynamicly, usually contains max 3 iframes(contentIFrame0, contentIFrame1, contentIFrame2), but the fact is that you never know they will be 2 or 1 on the page and why, so if you use today one of them directly - tommorow your tests will fail because of the changes.
It seems like I have to switch all the time to the last frame, but it works randomly, because sometimes there is the first one contains element and another one scripts. Other thing i tried to do, is to switch to one iframe which has attributes: style = visibility: visible(before that, i tried to print in console how many visible frames driver sees - but written all the time 0). Also, if i try to print in the console how many iframes there are on the page - the counter is 2, but I can see 3.
If there is anyone who tried to automate MS Dynamics 365 and had the same problem?
I have discribed probably all cases, maybe you will notice the logics and difference.
I am not sure if this works in your case but please give it a try.
If you know one of the elements in the frame which you are trying to switch then use the css selector or xpath
driver.switchTo().frame(driver.findElement(By.cssSelector("iframe[title='test']")));
It very hard to test in this fashion as Microsoft doesn't guarantee that the objects being rendered will stay the same. It may be 3 frames today, but in the next version the dev team may introduce more or less, working with the DOM directly is no longer supported.
I would highly recommend the following framework for testing Dynamics: https://github.com/Microsoft/EasyRepro
It will help elevate your testing up one level, it’s introducing a level of abstraction so as to minimize the need to work with HTML directly by isolating all that low-level work in the framework code.
Here is a great post about EasyRepro: http://www.itaintboring.com/dynamics-crm/easy-repro-what-is-it/
Goodluck
This xpath finds the main pane reliably
//iframe[contains(contains(#id,'contentIFrame') and contains(#style,'visible')]
Note: not applicable to Dynamics 365 Unified Interface, it has completely different DOM.
I am using selenium framework to automate a web application wherein basically, driver.findElement() is commonly used. but I got the suggestion that #FindBy() works faster than driver.findElement(). suggest me which is better to use ?
When the code - PageFactory.initElements(....) is run it creates Proxy objects for all the fields which are annotated with #FindBy (or even #FindBys and #FindAll). So initially no searching of WebElements are performed.
Then if something like element.sendKeys(...) is run, the actual WebElement is searched using driver.findElement(...) before sendKeys() is run. Then if the same sendKeys() code is run the element is found again.
But if you add the CacheLookup annotation to the field then the second lookup is not performed but element is returned from the cache. So there is a performance gain. But the problem occurs in a javascript or ajax heavy page, stale element exception can show up.
For any non-trivial application testing use the PageObjectModel framework. Makes things organized and not littered with findElements and locators, even if you do not use the CacheLookUp annotation.
I'm using using AutoHotkey to drive SeleniumBasic v2.0.9.0
I'm new to Selenium and have been looking at a lot of different pages discussing how to get/set elements on a webpage. I've noticed there seems to be (at least )two different types of format for syntax.
Here are two examples:
1. driver.findElementByID("search_form_input_homepage").SendKeys("hello")
2. driver.findElement(By.id("search_form_input_homepage")).SendKeys("hello")
In my case the first one works but the second throws an error saying No such interface supported. I'm just curious of the origin of the second structure. Is it from Selenium 3?
Here is the Answer to your Question:
driver.findElementByID("search_form_input_homepage").SendKeys("hello") : Is in use through the VBA module maintained by #FlorentB.
driver.findElement(By.id("search_form_input_homepage")).SendKeys("hello") : Is in use through the Java bindings of Selenium.
Let me know if this Answers your Question.
I am just thinking about command typeAndWait in Selenium, because I cant figure out any real purpose of it.
In what situation you type in some input and then the page immedeately starts reloading? I can imagine AJAX, but in this case the page doesn't reload - which is the reason, you have to use waitForXY commands instead of xyAndWait when testing AJAX...
But it was a long day today, maybe I am just dull now and the answer is quite obvious...
The google search while you type is the only situation I can think of where that would happen, except your right that the page wouldn't actually load, but there are some weird cases out there that I'm sure I haven't thought of.