A4Q Selenium Tester Examen de práctica #4 — Preguntas y respuestas
Todas las preguntas de este examen de práctica, con la respuesta correcta marcada y una justificación escrita para cada opción a continuación — para leer y repasar, no una prueba cronometrada.
¿Qué afirmación sobre el método de WebDriver driver.get(String url) es correcta?
Carga la página y, por defecto, espera a que se cargue por completo.
get() no devuelve el control hasta que la carga de la página finaliza.
Abre la URL en una nueva pestaña del navegador.
get() reutiliza la ventana actual; no abre una pestaña nueva.
Devuelve el título de la página como String.
get() devuelve void; getTitle() devuelve el título.
Nunca espera y devuelve de inmediato tras enviar la solicitud.
Por defecto get() es bloqueante.
get() navega a una URL y, por defecto, bloquea hasta que document.readyState sea 'complete'.
¿Cuál es la diferencia entre driver.getWindowHandle() y driver.getWindowHandles()?
getWindowHandle() devuelve un identificador actual; getWindowHandles() devuelve un Set de todos.
Correcto: el singular devuelve un String, el plural un Set<String>.
Ambos devuelven una List ordenada por hora de apertura.
Ninguno devuelve List; el plural devuelve un Set no ordenado.
getWindowHandle() cierra la ventana; getWindowHandles() las lista.
getWindowHandle() no cierra nada.
No hay diferencia; son alias.
Devuelven tipos y significados distintos.
getWindowHandle() devuelve el identificador de la ventana actual (String); getWindowHandles() devuelve un Set con todos los identificadores abiertos.
Una prueba hace clic en un enlace que abre una segunda pestaña con un formulario de pago. Antes del clic guardó el identificador original con String main = driver.getWindowHandle();. Tras el clic, la prueba debe interactuar con el formulario de la nueva pestaña, completarlo, cerrar esa pestaña y devolver el control a la página original. ¿Qué secuencia de llamadas de WebDriver realiza correctamente este cambio y la limpieza?
Iterar getWindowHandles(), switchTo().window(h) para el handle != main, completar el formulario, driver.close(), luego switchTo().window(main).
Correcto: cambiar a la nueva pestaña, actuar, cerrarla y volver explícitamente al identificador guardado.
Llamar solo a driver.switchTo().frame(1), completar y luego driver.quit().
frame() cambia iframes, no pestañas; quit() terminaría toda la sesión.
Completar el formulario directamente: WebDriver enfoca automáticamente la pestaña más nueva.
WebDriver NO cambia el foco automáticamente; hay que llamar a switchTo() de forma explícita.
Usar driver.navigate().forward() para entrar en la nueva pestaña y back() para volver.
navigate() controla el historial de una ventana, no el cambio entre pestañas.
Se itera el Set de identificadores, se cambia al que no es el original, se trabaja, se cierra la nueva pestaña y se vuelve al identificador main guardado.
Cuando no existe ningún elemento coincidente en la página, ¿cómo se comportan findElement() y findElements()?
findElement() lanza NoSuchElementException; findElements() devuelve una lista vacía.
Es el contrato definido de ambos métodos.
Ambos devuelven null.
findElement() lanza; findElements() devuelve lista vacía.
Ambos lanzan NoSuchElementException.
findElements() no lanza si no hay coincidencia; devuelve lista vacía.
findElement() devuelve lista vacía; findElements() lanza.
Invierte el comportamiento real.
findElement() lanza NoSuchElementException; findElements() devuelve una lista vacía.
¿Cuáles de las siguientes son responsabilidades legítimas de la API de Selenium WebDriver? (Elija dos.)
Controlar un navegador real mediante su automatización nativa.
Propósito central de WebDriver.
Localizar elementos y simular interacciones del usuario con ellos.
WebDriver encuentra elementos y hace clic/escribe.
Proporcionar métodos de aserción para verificar resultados esperados.
Las aserciones vienen del framework de pruebas, no de WebDriver.
Programar y ejecutar la suite de pruebas en paralelo.
La ejecución la gestionan el ejecutor y Grid, no la API de WebDriver.
WebDriver controla un navegador real mediante su automatización nativa y localiza/interactúa con elementos. No es un ejecutor de pruebas ni incluye aserciones.
Debe pasar el ratón sobre un elemento de menú para mostrar un submenú y luego hacer clic en un enlace que solo aparece durante el hover. Un clic simple falla porque el enlace no es visible hasta el hover. ¿Qué enfoque de Selenium realiza de forma fiable el hover-y-clic como un solo gesto?
new Actions(driver).moveToElement(menu).click(submenuLink).perform();
Actions encadena mover el ratón y hacer clic en un gesto ejecutado por perform().
submenuLink.click(); llamado dos veces seguidas.
Repetir el clic no genera el estado de hover que revela el enlace.
driver.navigate().refresh(); luego submenuLink.click();
Refrescar no hace hover; el enlace sigue oculto.
menu.sendKeys(Keys.ENTER); luego submenuLink.click();
Enviar ENTER no es un hover y puede no abrir el submenú :hover de CSS.
La clase Actions crea un gesto compuesto: moveToElement(menu), luego click(submenuLink), finalizado con perform().
¿Cuál es la diferencia entre driver.close() y driver.quit()?
close() cierra la ventana actual; quit() cierra todas y finaliza la sesión.
Es la distinción precisa entre ambos métodos.
Son idénticos.
Difieren en alcance: una ventana vs toda la sesión.
close() finaliza toda la sesión; quit() cierra una ventana.
Invierte el comportamiento real.
Ambos mantienen el proceso del driver para reutilizarlo.
quit() termina el proceso del driver.
close() cierra la ventana actual; quit() cierra todas las ventanas y finaliza la sesión de WebDriver.
¿Qué método de WebElement se debe usar para borrar un valor existente de un campo de texto antes de escribir uno nuevo?
clear()
clear() elimina el contenido actual de un campo editable.
reset()
No existe reset() en WebElement.
delete()
No existe el método delete().
submit()
submit() envía el formulario; no borra el campo.
clear() vacía el campo; luego sendKeys() escribe el nuevo valor.
¿Qué estrategia By suele ser la más rápida y robusta cuando un elemento tiene un atributo id único y estable?
By.id
Un id es único por página y se resuelve rápido.
By.xpath con ruta absoluta
El XPath absoluto es frágil y lento.
By.linkText
linkText solo sirve para el texto de enlaces.
By.tagName
tagName coincide con muchos elementos y no es único.
By.id apunta directamente al atributo id y es el localizador preferido cuando existe un id único estable.
Dado el marcado: <div class="card"><button class="btn btn-primary submit-order" data-test="place-order">Place order</button></div> — los valores de clase cambian entre versiones, pero el atributo data-test es estable. ¿Qué localizador apunta a este botón de forma más mantenible?
By.cssSelector("button[data-test='place-order']")
Apunta al atributo estable, ajeno a los cambios de clase.
By.className("btn btn-primary submit-order")
className solo acepta un nombre de clase, y estas cambian.
By.cssSelector(".btn-primary")
Depende de una clase volátil y puede coincidir con otros botones.
By.xpath("/html/body/div[1]/div/button")
La ruta absoluta se rompe con cualquier cambio estructural.
Un selector CSS de atributo sobre el estable data-test es conciso y resistente a los cambios de clase.
Necesita un XPath que seleccione un elemento <a> por su texto visible exacto 'Log out'. ¿Qué expresión es correcta?
//a[text()='Log out']
Selecciona el ancla cuyo texto es igual a la cadena dada.
//a[@text='Log out']
text no es un atributo sino un nodo; @text no es válido.
//a=='Log out'
Sintaxis XPath no válida.
//a(text='Log out')
Sintaxis XPath no válida.
//a[text()='Log out'] coincide con anclas cuyo nodo de texto es exactamente 'Log out'.
¿Qué selector CSS coincide con un input cuyo id es exactamente 'email'?
input#email
# selecciona por id en CSS.
input.email
. selecciona por clase, no por id.
input=email
Sintaxis CSS no válida.
input@email
Sintaxis CSS no válida.
En CSS, # denota un id, por lo que input#email apunta al elemento con id 'email'.
¿Qué dos estrategias de localización se consideran frágiles y deben evitarse cuando hay un id o atributo data estable? (Elija dos.)
XPath absoluto como /html/body/div[2]/form/input[1]
Cualquier cambio estructural rompe la ruta.
Selectores basados en clases autogeneradas como css-1a2b3c
Los hashes del framework cambian al recompilar.
By.id sobre un id único estable
Es la estrategia más robusta.
Un selector CSS de atributo sobre un data-test estable
Los atributos data-test están pensados para automatización y son estables.
El XPath absoluto y los localizadores basados en nombres de clase autogenerados volátiles se rompen fácilmente.
¿Qué expresión de eje XPath selecciona un <label> que es el padre inmediato del nodo de contexto?
parent::label
El eje parent con prueba de nodo selecciona el label padre.
child::label
child selecciona hijos, no el padre.
following-sibling::label
Selecciona un hermano, no el padre.
descendant::label
descendant busca hacia abajo, no al padre.
.. (o parent::label) se mueve al nodo padre.
Una tabla de resultados tiene muchas filas. Debe hacer clic en el botón 'Edit' de la fila cuya primera celda contiene 'INV-1042'. Las filas tienen la estructura <tr><td>INV-1042</td>...<td><button>Edit</button></td></tr>. ¿Qué XPath hace clic de forma fiable en el botón Edit correcto?
//td[text()='INV-1042']/ancestor::tr//button[text()='Edit']
Se ancla en el texto único de la celda y limita el botón a esa fila.
//button[text()='Edit']
Coincide con todos los botones Edit, no con una fila específica.
//td[text()='INV-1042']/button
El botón no es hijo directo de ese td.
//tr[1]//button[text()='Edit']
Fija la primera fila, ignorando de qué factura se trata.
Se ancla en el texto del td y se navega al botón de la misma fila mediante el ancestro tr.
¿Qué selector CSS coincide con un elemento que tiene AMBAS clases 'nav' y 'active'?
.nav.active
Sin espacio: ambas clases en el mismo elemento.
.nav .active
Un espacio es el combinador de descendiente.
.nav > .active
> es el combinador de hijo directo.
.nav,.active
Una coma es una agrupación (O lógico).
Encadenar selectores de clase sin espacio (.nav.active) exige ambas clases en el mismo elemento.
¿Cuál es el propósito principal del patrón Page Object Model (POM) en la automatización con Selenium?
Encapsular localizadores e interacciones de una página para que las pruebas sean legibles y el mantenimiento esté centralizado.
Beneficio central: separar la estructura de la página de la lógica de prueba.
Reemplazar la necesidad de un framework como JUnit o TestNG.
POM complementa, no reemplaza, el framework.
Hacer que el navegador vaya más rápido almacenando páginas en caché.
POM es un patrón de diseño; no afecta al rendimiento.
Generar datos de prueba automáticamente para cada página.
La generación de datos no tiene relación con POM.
POM encapsula los localizadores e interacciones de una página en una clase; las pruebas usan métodos legibles y los cambios de localizador se hacen en un solo lugar.
El objeto LoginPage de un equipo expone un método que escribe usuario y contraseña, hace clic en enviar y luego devuelve un objeto DashboardPage. Un revisor dice que es buena práctica de POM. ¿Por qué se considera un buen patrón devolver el siguiente page object desde un método de acción?
Modela el flujo de navegación y permite encadenar llamadas de forma fluida y con seguridad de tipos.
Correcto: la acción lleva a una nueva página; devolverla refleja el recorrido real.
Porque permite que el page object contenga las aserciones.
Las aserciones van en las pruebas, no en los page objects.
Porque hace que la instancia de WebDriver sea global y estática.
Los drivers globales estáticos son un antipatrón.
Porque evita la necesidad de localizadores en la clase de página.
Los page objects siguen conteniendo localizadores.
Devolver el page object resultante modela el flujo de navegación y da a las pruebas una cadena fluida y con seguridad de tipos.
¿Qué dos prácticas son coherentes con un Page Object Model bien diseñado? (Elija dos.)
Mantener los localizadores privados y exponer el comportamiento mediante métodos claros.
La encapsulación es central en POM.
Cada página (o componente relevante) tiene su propia clase.
Una clase por página/componente mantiene claras las responsabilidades.
Colocar las aserciones dentro de los métodos del page object.
Las aserciones van en la capa de prueba.
Poner llamadas fijas a Thread.sleep() en cada método para dar estabilidad.
Los sleeps fijos son un antipatrón; se prefieren las esperas explícitas.
Los page objects deben mantener los localizadores privados y exponer métodos que revelen la intención; no deben contener aserciones.
En un Page Object Model, ¿dónde se debe proporcionar normalmente la instancia de WebDriver a un page object?
Inyectado a través del constructor del page object.
La inyección por constructor es el enfoque estándar.
Creado con new dentro de cada método.
Crear un driver por método abriría muchos navegadores y perdería el estado.
Leído de un campo global public static fijo.
El estado global estático perjudica el paralelismo.
Descargado de un servidor remoto en cada llamada.
No tiene sentido.
El driver suele inyectarse mediante el constructor, manteniendo el objeto comprobable y sin estado global.
Un equipo observa que los localizadores de un encabezado compartido en diez páginas están copiados en diez clases. ¿Qué refinamiento de POM elimina esta duplicación?
Extraer el encabezado a su propio objeto de componente reutilizado por las demás páginas.
Un objeto de componente compartido centraliza los localizadores y métodos del encabezado.
Copiar los localizadores otra vez en una clase base de prueba.
Añade otra copia en lugar de eliminar la duplicación.
Reemplazar todos los localizadores del encabezado por XPath absoluto.
Cambia el estilo pero mantiene la duplicación.
Eliminar por completo las pruebas del encabezado.
Quitar cobertura no es una refactorización válida.
Extraer el encabezado a su propio objeto de componente/página que las demás páginas usan, para que sus localizadores vivan en un solo lugar.
¿Qué afirmación describe mejor la relación entre page objects y clases de prueba?
Las pruebas llaman a métodos del page object para actuar y luego verifican los resultados.
Separación limpia: acciones en el page object, aserciones en la prueba.
Los page objects llaman a las clases de prueba para ejecutar aserciones.
La dirección de dependencia está invertida.
Son la misma clase con dos nombres.
Son capas distintas con responsabilidades distintas.
No hay interacción; se ejecutan de forma independiente.
Las pruebas deben llamar a los page objects.
Las clases de prueba llaman a los métodos del page object y luego verifican los resultados; el page object oculta el cómo, la prueba indica el qué.
¿En qué se diferencia una espera implícita de una espera explícita en Selenium WebDriver?
La implícita se aplica globalmente a las búsquedas; la explícita espera una condición definida sobre un elemento concreto.
Es la distinción definitoria entre ambos tipos.
Las esperas implícitas son más precisas que las explícitas.
Las explícitas son la opción precisa basada en condiciones.
Las esperas explícitas se aplican automáticamente a cada comando.
Eso describe una espera implícita.
No hay diferencia; ambas son alias.
Son mecanismos realmente distintos.
Una espera implícita se aplica globalmente a todos los findElement; una espera explícita (WebDriverWait) espera una condición concreta sobre un elemento concreto.
Una página envía un formulario por AJAX. Tras hacer clic en 'Save', un banner de éxito con id 'toast-success' aparece unos 1–3 segundos después. La prueba falla de forma intermitente porque comprueba el banner de inmediato. Con una espera explícita, ¿qué llamada sincroniza mejor con la aparición del banner?
wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("toast-success")))
Espera con precisión a que el banner sea visible, eliminando la condición de carrera.
Thread.sleep(3000) antes de comprobar el banner.
Un sleep fijo es frágil: corto falla, largo malgasta tiempo.
Aumentar solo la espera implícita a 30 segundos.
La implícita no comprueba visibilidad y mezclarla con la explícita se desaconseja.
Llamar a driver.navigate().refresh() y comprobar de nuevo.
Refrescar descartaría el resultado AJAX y el banner.
WebDriverWait con ExpectedConditions.visibilityOfElementLocated(By.id("toast-success")) sondea hasta que el banner es visible o se agota el tiempo.
¿Por qué se desaconseja mezclar esperas implícitas y explícitas en la misma prueba?
Puede causar tiempos de espera impredecibles y a veces mucho más largos.
La interacción entre ambos mecanismos es indefinida y puede sumar retrasos.
Usar ambas es un error de compilación.
Compila; el problema es el comportamiento en tiempo de ejecución.
Las esperas explícitas dejan de funcionar por completo si hay una implícita.
Siguen funcionando, pero el tiempo se vuelve impredecible.
Duplica el uso de memoria del navegador.
Las esperas no afectan de forma relevante a la memoria.
Combinarlas puede producir tiempos de espera impredecibles y más largos, porque los dos mecanismos interactúan de forma no aditiva.
¿Qué ExpectedCondition es la más adecuada cuando se debe esperar a que un botón no solo esté presente en el DOM sino que sea clicable?
ExpectedConditions.elementToBeClickable(locator)
Garantiza que el elemento sea visible y esté habilitado antes del clic.
ExpectedConditions.presenceOfElementLocated(locator)
La presencia solo comprueba el DOM; puede estar oculto o deshabilitado.
ExpectedConditions.titleIs("Home")
Comprueba el título de la página, no el botón.
ExpectedConditions.alertIsPresent()
Espera una alerta de JavaScript, no un botón.
elementToBeClickable espera a que el elemento sea visible y esté habilitado, condición previa para un clic fiable.
¿Cuál es la principal ventaja de FluentWait frente a un WebDriverWait básico?
Se puede fijar el intervalo de sondeo e ignorar tipos de excepción elegidos.
FluentWait expone pollingEvery e ignoring.
Elimina la necesidad de localizadores.
FluentWait sigue necesitando una condición.
Se ejecuta sin tiempo de espera, esperando para siempre.
FluentWait sigue teniendo un tiempo máximo.
Reintenta automáticamente toda la prueba si falla.
FluentWait sondea una condición; no reintenta pruebas.
FluentWait permite configurar el intervalo de sondeo e ignorar tipos de excepción concretos mientras espera.
¿Por qué se considera que las llamadas fijas a Thread.sleep() son una mala estrategia de sincronización?
Ignora el estado real de la aplicación, malgastando tiempo o fallando igual.
Los retrasos fijos no se adaptan a tiempos de respuesta variables.
Solo funciona en modo headless.
Thread.sleep() funciona independientemente del modo headless.
Lanza NoSuchElementException por diseño.
sleep() solo pausa el hilo.
El lenguaje Java no lo admite.
Thread.sleep() es Java estándar.
Un sleep fijo malgasta tiempo cuando la app es rápida o sigue fallando cuando es lenta, porque no reacciona al estado real.
¿Qué método recarga la página actual en Selenium WebDriver?
driver.navigate().refresh()
Es el método dedicado para recargar.
driver.reload()
No existe el método reload().
driver.get()
get() necesita una URL; refresh() recarga la actual.
driver.switchTo().refresh()
switchTo() cambia de contexto; no tiene refresh().
driver.navigate().refresh() recarga la página actual.
Para interactuar con un elemento que está dentro de un <iframe>, ¿qué debe hacer primero la prueba?
Cambiar al frame con driver.switchTo().frame(...).
Los elementos del iframe solo son accesibles tras cambiar a él.
Nada especial; los elementos del iframe se encuentran como cualquier otro.
Sin cambiar, findElement no ve los elementos del iframe.
Llamar a driver.quit() e iniciar una nueva sesión.
Descarta la sesión y no ayuda.
Borrar primero todas las cookies.
Las cookies no tienen relación con entrar al iframe.
Hay que cambiar el contexto del driver al frame (switchTo().frame(...)) antes de localizar elementos dentro.
Una prueba introduce datos en un campo dentro de un iframe (id 'editor') y luego debe hacer clic en un botón 'Publish' que está en la página principal FUERA del iframe. Tras escribir en el iframe, ¿qué debe hacer la prueba antes de pulsar Publish y por qué?
Llamar a driver.switchTo().defaultContent() para volver al documento principal, porque el driver sigue en el iframe.
El contexto permanece en el iframe hasta que se vuelve explícitamente al contenido por defecto.
Nada: pulsar Publish funciona porque está en la misma página.
El driver sigue dentro del iframe y no ve el botón externo.
Llamar de nuevo a driver.switchTo().frame('editor').
Eso volvería a entrar al iframe.
Eliminar el iframe con JavaScript antes de hacer clic.
Destruir el iframe es destructivo e innecesario.
Tras trabajar dentro de un frame, hay que usar switchTo().defaultContent() para volver al documento de nivel superior antes de encontrar elementos fuera del iframe.
Se muestra una alerta nativa de JavaScript (window.alert). ¿Qué llamada de Selenium acepta (pulsa OK) la alerta?
driver.switchTo().alert().accept()
Se cambia a la alerta y accept() pulsa OK.
driver.findElement(By.id('ok')).click()
Una alerta nativa no forma parte del DOM.
driver.navigate().accept()
navigate() no tiene método accept().
driver.close()
close() cierra la ventana en vez de aceptar la alerta.
driver.switchTo().alert().accept() cambia a la alerta y la acepta.
Para seleccionar la opción con el texto visible 'Germany' de un elemento HTML <select> estándar, ¿qué clase de apoyo de Selenium está diseñada para esto?
La clase Select, p. ej. new Select(element).selectByVisibleText("Germany").
Select es la ayuda dedicada para desplegables <select>.
La clase Actions con doubleClick().
Actions maneja gestos complejos, no la selección en <select>.
La clase Alert.
Alert maneja diálogos de JavaScript.
La clase WebDriverWait.
WebDriverWait maneja la sincronización.
La clase Select ofrece selectByVisibleText, selectByValue y selectByIndex para elementos HTML <select>.
¿Qué llamada de navegación mueve el navegador a la página anterior del historial?
driver.navigate().back()
Retrocede una entrada en el historial.
driver.back()
back() está en el objeto Navigation, vía navigate().
driver.previous()
No existe previous().
driver.navigate().history(-1)
Navigation no tiene history().
driver.navigate().back() equivale al botón Atrás del navegador.
Un pipeline de CI ejecuta 200 pruebas de UI. Unas 8 pasan en local pero fallan aproximadamente una de cada cinco ejecuciones en CI, siempre en pasos sensibles al tiempo en torno a actualizaciones AJAX. En local se ejecutan en máquinas rápidas; los agentes de CI son más lentos y compartidos. ¿Qué causa raíz y solución explican y resuelven mejor estos fallos intermitentes?
Sincronización insuficiente: las pruebas asumen tiempos; sustituir los sleeps fijos por esperas explícitas sobre la condición de finalización de AJAX.
Las esperas explícitas se adaptan a los agentes de CI más lentos.
La aplicación tiene un error real; desactivar las 8 pruebas de forma permanente.
Los fallos son por tiempos y entorno, no un defecto reproducible del producto.
CI es intrínsecamente poco fiable; reejecutar hasta que pase.
Reejecutar a ciegas oculta la inestabilidad y posibles regresiones.
Añadir un Thread.sleep(10000) global a cada prueba.
Sleeps fijos enormes malgastan tiempo y no garantizan nada.
El síntoma — fallos intermitentes en agentes de CI más lentos y compartidos en pasos AJAX — apunta a sincronización insuficiente; sustituir los sleeps fijos por esperas explícitas sobre la condición esperada es la solución correcta.
¿Qué es una prueba 'flaky' (inestable)?
Una prueba que pasa y falla de forma intermitente con el mismo código.
Los resultados no deterministas definen la inestabilidad.
Una prueba que siempre falla.
Una prueba que siempre falla es determinista.
Una prueba con más de 100 pasos.
La longitud no define la inestabilidad.
Una prueba escrita en un lenguaje de scripting.
El lenguaje no tiene relación con la inestabilidad.
Una prueba flaky da resultados distintos (pasa/falla) con el mismo código sin cambios, normalmente por tiempos, orden o entorno.
¿Qué dos prácticas mejoran la estabilidad e independencia de una suite de pruebas de UI automatizadas? (Elija dos.)
Hacer que cada prueba cree y limpie sus propios datos para que no dependan entre sí.
La independencia evita fallos en cascada por orden.
Sincronizar con esperas explícitas sobre condiciones significativas en vez de retrasos fijos.
Las esperas por condición se adaptan a la variabilidad de tiempos.
Dejar que las pruebas compartan y reutilicen datos de pruebas anteriores para ahorrar tiempo.
El estado compartido acopla las pruebas y causa inestabilidad por orden.
Añadir generosas llamadas fijas a Thread.sleep() por todas partes por seguridad.
Los sleeps fijos ralentizan la suite y no garantizan nada.
Pruebas independientes que crean y limpian sus propios datos, junto con esperas robustas, reducen la inestabilidad. Compartir estado y usar sleeps fijos perjudican.
Se lanza una StaleElementReferenceException. ¿Qué suele indicar?
La referencia al elemento ya no está adjunta al DOM (la página se re-renderizó).
Volver a localizar el elemento tras el cambio del DOM lo resuelve.
El navegador se quedó sin memoria.
La excepción trata de un elemento desvinculado, no de memoria.
La sintaxis del localizador no es válida.
La sintaxis inválida lanza otra excepción.
El framework de pruebas está mal configurado.
Es una condición del DOM en tiempo de ejecución.
Significa que una referencia a un WebElement ya no está adjunta al DOM, normalmente porque la página o parte de ella se volvió a renderizar.
¿Qué enfoque mantiene mejor la independencia de las pruebas de UI para que puedan ejecutarse en cualquier orden o en paralelo?
Cada prueba crea sus propias precondiciones y limpia sus propios datos.
Las pruebas autocontenidas se ejecutan en cualquier orden y en paralelo.
Ejecutar las pruebas en un orden fijo y depender de datos de pruebas anteriores.
La dependencia de orden impide el paralelismo.
Guardar estado compartido en variables estáticas entre todas las pruebas.
El estado estático compartido acopla las pruebas.
No reiniciar nunca el navegador entre pruebas.
El estado residual del navegador se filtra entre pruebas.
Cada prueba debe crear el estado que necesita y limpiar después, para que ninguna dependa de los efectos de otra.
Una prueba a veces lanza StaleElementReferenceException justo después de que la cuadrícula de resultados se recarga. ¿Cuál es la solución más robusta?
Volver a buscar el elemento tras recargar la cuadrícula, con una espera explícita.
Una búsqueda nueva tras el cambio del DOM da una referencia válida.
Capturar la excepción e ignorarla en silencio.
Silenciar el error oculta el problema.
Aumentar el tamaño de la ventana del navegador.
El tamaño de la ventana no tiene relación.
Guardar la referencia del elemento en un campo estático para reutilizarla.
Cachear la referencia entre cambios del DOM aumenta la obsolescencia.
Volver a localizar el elemento tras la actualización del DOM (idealmente con una espera explícita) para tener una referencia nueva.