Cuando escribes pruebas funcionales utilizando Selenio, la mayor parte de tu código consistirá en interacciones con la interfaz web que estás probando a través de la API de WebDriver. Después de obtener los elementos, verificarás algún estado del elemento a través de varias afirmaciones y pasarás a obtener el siguiente elemento.
Considere este ejemplo como parte de una prueba básica de Selenio:
123456789List<WebElement;;zipCodes = driver.findElements(By.id("zipCodes"));for(WebElement zipCode : zipCodes){if(zipCode.getText(). es igual a("12345")){ zipCode.click();break;}}WebElement city = driver.findElement(By.id("city"));assertEquals("MyCityName", city.getText());java
Este es un ejemplo simple de una prueba que busca e itera sobre una lista de códigos postales buscando 12345, haciendo clic en él y buscando el elemento de la ciudad esperando que el nombre de la ciudad sea MyCityName.
Incluso con una prueba tan simple como esta, la legibilidad es muy pobre. Hay mucho código de WebDriver, que oscurece el propósito de la prueba, haciéndola lenta y difícil de digerir.
Con cualquier interfaz, y supongo que con las interfaces web en particular, es común que tanto los cambios menores como los mayores en la interfaz se implementen con frecuencia. Esto podría ser un nuevo diseño, la reestructuración de los campos y botones, y esto probablemente impactará en su prueba. Así que tu prueba falla y necesitas actualizar tus selectores.
Ahora bien, si sólo tienes una prueba funcional para una página que resuma el «camino feliz», puede que no consideres esto como algo importante.
Así que algunos de los problemas típicos para este tipo de prueba de Selenio son:
- Los casos de prueba son difíciles de leer
- Cambios en la UI rompe múltiples pruebas a menudo en varios lugares
- Duplicación de selectores tanto dentro como a través de las pruebas – sin reutilización