how - xpath selenium java

WebDriver findElement por xPath, sin TIMEOUT si el elemento no se encuentra, la pantalla simplemente se cuelga allí.

Question

Me enfrento a un problema por el cual la prueba se cuelga allí (el navegador está abierto y no puede continuar con la siguiente prueba) debido a que mi declaración de prueba no puede encontrar el elemento.

Mi TestStatemet así:

driver.findElement(By.xpath("//input[@name=''AID'' and contains(@value,''sampleDataThatwillNotFound'')]"));

La prueba se cuelga solo cuando se encuentra por XPATH, no hay problema cuando se encuentra con NAME / ID. Había establecido el tiempo de espera en 60 segundos, después de los 60 segundos, todavía se cuelga.

¿Alguien que está frente a este problema antes? o ¿Alguien tiene alguna idea de cómo resolver este problema?

Answer 1

Prueba este localizador

driver.findElement(By.xpath("//input[@name=''AID''][contains(@value,''sampleDataThatwillNotFound'')]"));

Answer 2

Bueno, tuve el mismo problema y encontré esto en webdriver api doc : findElement no debería usarse para buscar elementos no presentes, usar findElements(By) y afirmar la respuesta de longitud cero en su lugar.

Entonces uso algo como

List<WebElement> found = driver.findElements(By.id("elementid"));
if (found.size() > 0)
{
// get the 1st element
} else {
// time out
}

para resolver este problema Y el tiempo de espera implícito funciona bien con findElements en mi caso.

Answer 3

Obtuve algunos comentarios de Darrell de Google Groups, y estoy de acuerdo con él, a continuación se muestra su opinión: https://groups.google.com/forum/#!topic/webdriver/Vt0DuQHOAg8

* No he visto estos localizadores colgando, pero todo es posible. En general, si el DOM es grande y / o complejo, un localizador de combinación (uno con contiene más un y) podría hacerlo realmente lento. Mi experiencia general ha sido que cuanto más complejo sea el localizador, más tiempo tomará. Cuanto más tiempo tarde, más probable es que veas una NoSuchElementException. Podría ser que otra cosa que estás haciendo esté causando un segundo problema, es decir, el ahorcamiento. Una declaración y está multiplicándose. Entonces @ name = ''AID'' es relativamente rápido. No hay comprobación de subcadenas. O coincide o no. Entonces este localizador se ejecutará en orden n, donde n es el número de etiquetas de entrada. Un localizador como contiene (@value, ''someString'') tendrá que escanear cada etiqueta para cada atributo para una coincidencia con cada posible subcadena. Si el contains () se implementa bien, podría ser un poco más rápido que la fuerza bruta, pero el tipo de datos en el DOM determinará cuánto tiempo llevará esta búsqueda. Definitivamente será lento. Ahora, si toma la búsqueda contains () (relativa lenta) y la coincidencia exacta (relativamente rápida), luego busque la AND de las dos coincidencias, las está multiplicando. Se realizarán dos coincidencias exactas orden n veces orden n (o n cuadrado). Esto no está bien. Un tiempo de coincidencia exacto que contiene es REALMENTE malo. Dependiendo del DOM, podría ordenarse en cubos. Esto significa que si n toma 10 segundos, n en cubos es 10 * 10 * 10 segundos (1000 segundos o más de 16 minutos). Si el DOM causa que las cosas empeoren, podría estar buscando la coincidencia exacta en segundos y la combinación en horas. Darrell *

Entonces, para resolver este problema, creo que es hora de hacer que el equipo de desarrollo se aplique a la práctica de desarrollo común para colocar una identificación única para cada elemento / control. De modo que la secuencia de comandos de automatización de prueba puede realizar directamente cualquier verificación / entrada a través de ID, en lugar de xPath.

Answer 4

He intentado alguna respuesta más arriba, pero todavía tengo los mismos problemas. Vuelvo a la versión anterior de Firefox 17.0.3 ... todo acaba de resolver ... un poco raro ... aquellos que enfrentan el mismo problema pueden probar en la Versión 17.0 de FF. .3

Answer 5

Estaba teniendo el mismo problema después de actualizar Firefox (25 a 26) y Selenium (2.37.1 a 2.39.0 controlador + servidor). No se lanza ninguna excepción, cuelga para siempre, etc. Se "solucionó" eliminando la declaración implicitlyWait espera. No es una solución real, pero es lo suficientemente bueno en mi caso.