WebDriver findElement by xPath, no TIMEOUT, if no element is found the screen just hangs there.
I am facing some kind of problem where the test just hangs there (the browser is open and cannot continue with the next test) due to my test that cannot find the item.
My TestStatemet:
driver.findElement(By.xpath("//input[@name='AID' and contains(@value,'sampleDataThatwillNotFound')]"));
The test hangs only when searching by XPATH, no problems when searching by NAME / ID. I set the timeout to 60 seconds, after 60 seconds it still hangs.
Does anyone else have this problem? or has anyone figured out how to solve this problem?
source to share
Well I had the same problem and found this in the webdriver api doc :
findElement
should not be used to find non-expert items, use findElements(By)
and provide a zero length answer instead.
So, I am using something like
List<WebElement> found = driver.findElements(By.id("elementid"));
if (found.size() > 0)
{
// get the 1st element
} else {
// time out
}
to solve this problem. And the implicit timeout works fine with findElements
in my case.
source to share
I got some feedback from darrell from Google Groups and I agree with him, below is his feedback: https://groups.google.com/forum/#!topic/webdriver/Vt0DuQHOAg8
* I have not seen these locators hanging, but anything is possible. Typically, if the DOM is large and / or complex, a combination locator (one with contains plus an and) could make it very slow. My general experience was more challenging than a locator. The longer it takes, the more likely you are to see a NoSuchElementException. It is possible that something else you are doing is causing the second problem, i.e. freezing. The operator an and is multiplied. So @ name = "AID" is relatively fast. No substring validation. It either matches or it doesn't. So this locator will work in order n, where n is the number of input tags. A content-like locator (@value, 'someString') would have to scan every tag for every attribute to match every possible substring. If contains () is well implemented, it might be slightly faster,than the rough but the datatype in the DOM will determine how long this lookup will take. It will definitely be slow. Now, if you take a search for contains () (relatively slow) and exact (relatively fast), then search for AND of two matches, you multiply them. Two exact matches will be n times order n (or n square). This is not good. Exact timing is REALLY bad. Depending on the DOM, this could be cube order n. This means that if n takes 10 seconds, n cubic 10 * 10 * 10 seconds (1000 seconds or more than 16 minutes). If the DOM is causing it to be even worse, you can look at the exact match - seconds and clock combination. Darrell *if you take a search for contains () (relatively slow) and exact (relatively fast), then search for AND of two matches, you multiply them. Two exact matches will be n times order n (or n square). This is not good. Exact timing is REALLY bad. Depending on the DOM, this could be cube order n. This means that if n takes 10 seconds, n cubic 10 * 10 * 10 seconds (1000 seconds or more than 16 minutes). If the DOM is causing it to be even worse, you can look at the exact match - seconds and clock combination. Darrell *if you take a search for contains () (relatively slow) and exact (relatively fast), then search for AND of two matches, you multiply them. Two exact matches will be n times order n (or n square). This is not good. The exact timing is REALLY bad. Depending on the DOM, this could be cube order n. This means that if n takes 10 seconds, n cubic 10 * 10 * 10 seconds (1000 seconds or more than 16 minutes). If the DOM is causing it to be even worse, you can look at the exact match - seconds and clock combination. Darrell *n cubic 10 * 10 * 10 seconds (1000 seconds or more than 16 minutes). If the DOM is causing it to be even worse, you can look at the exact match - seconds and clock combination. Darrell *n cubic 10 * 10 * 10 seconds (1000 seconds or more than 16 minutes). If the DOM is causing it to be even worse, you can look at the exact match - seconds and clock combination. Darrell *
So, to solve this problem, I think it's time to get the development team to apply to general development practice to put a unique ID for each item / control. So that the test automation script can do any validation / input directly via id instead of xPath.
source to share