Malas prácticas

Things to avoid when automating browsers with Selenium.

Page being translated from English to Spanish. Do you speak Spanish? Help us to translate it by sending us pull requests!

1 - Captchas

CAPTCHA, short for Completely Automated Public Turing test to tell Computers and Humans Apart, is explicitly designed to prevent automation, so do not try! There are two primary strategies to get around CAPTCHA checks:

  • Disable CAPTCHAs in your test environment
  • Add a hook to allow tests to bypass the CAPTCHA

CAPTCHA es la abreviatura de Completely Automated Public Turing test to tell Computers and Humans Apart o en español Prueba de Turing Completamente Automática y Pública para diferenciar Ordenadores de Humanos, está explícitamente diseñado para prevenir la automatización, ¡así que no intentes automatizarlo!

Existen dos estrategias principales para evitar los CAPTCHAs:

  • Deshabilitar los CAPTCHAs en tus entornos de pruebas.
  • Agrega un parámetro que permita que las pruebas hagan un baipás.

2 - Descarga de archivos

Mientras que es posible empezar una descarga haciendo clic en el enlace, con el navegador que este siendo controlado por Selenium, el API no expone el progreso de la descarga, haciéndolo poco ideal para probar la descarga de archivos. Esto es debido a que descargar archivos no es considerado un aspecto importante de la emulación de las interacciones de los usuarios con las plataformas web. En lugar de ello, se recomienda encontrar el enlace con Selenium (y cualquier Cookie requerida) y pasarselo a una librería que permita hacer peticiones HTTP como libcurl.

El HtmlUnit driver puede descargar archivos adjuntos accediendo a ellos como flujos de entrada mediante la implementación de la interfaz AttachmentHandler. El AttachmentHandler se puede agregar al HtmlUnit WebClient.

3 - Códigos de respuesta HTTP

Para algunas configuraciones de navegadores en Selenium RC, Selenium actuaba como proxy entre el navegador y el sitio web que iba a ser automatizado. Esto significaba que todo el trafico que pasaba a través de Selenium podía ser capturado o manipulado. El método captureNetworkTraffic() pretendía capturar todo el trafico de red entre el navegador y el sitio que estaba siendo automatizado, incluyendo los códigos de respuestas HTTP.

El WebDriver de Selenium parte de una aproximación completamente diferente respecto a la automatización de los navegadores, prefiriendo así actuar mas como un usuario y esto se representa en la forma en la que escribes los tests con el WebDriver. Para los tests funcionales automatizados comprobar el código de respuesta no es un detalle particularmente importante en un test fallido, los pasos que se han realizado lo son mucho mas.

El navegador siempre representará el código de estado de respuesta HTTP, imagina por ejemplo una pagina de error para los códigos 404 o 500. Un forma simple de hacer fallar el test cuando encuentras una de estas paginas de error es validar los títulos de las paginas o algún contenido de confianza (ej. la etiqueta <h1>) después de que se haya cargado cada pagina. Si estas usando un modelo basado en el patrón page object puedes incluir esta validación en el constructor de la clase o en puntos similares donde se espere la carga de una pagina. En algunas ocasiones el código de respuesta HTTP puede llegar a ser representado en la pagina de error en el navegador e incluso podrías usar el WebDriver para leerlo y facilitar la depuración en tus tests.

Comprobar la pagina web es la linea de trabajo ideal del WebDriver representando y validando así la vista de los usuarios de los sitios web.

Si aun así necesitases una forma de capturar los códigos de respuesta HTTP una forma avanzada es replicar el comportamiento de Selenium RC usando un proxy. El API del WebDriver provee la habilidad de configurar un proxy para un navegador, existen una gran cantidad de proxies que te permiten programaticamente manipular los contenidos de las peticiones enviadas y recibidas desde los servidores web. Usar un proxy te permite decidir como actuar frente a redirecciones. Ademas, no todos los navegadores hacen que los códigos de respuesta estén disponibles para el WebDriver, es por eso que optar por un proxy te permitirá disponer de una solución común para todos los navegadores.

4 - Autenticarse con Gmail, email y Facebook

Por múltiples razones, autenticarse en sitios como Gmail y Facebook usando el WebDriver no esta recomendado. Aparte de estar en contra de los términos y condiciones de estos sitios (te expones a que te cierren la cuenta), es un proceso lento y poco fiable.

La practica ideal respecto a estos los sitios de emails es usar las APIs que ofrecen, en el caso de Facebook usar las herramientas para desarrolladores las cuales exponen un API para crear cuentas de prueba, amigos, etc. A pesar de que usar un API puede parecer como un esfuerzo extra, lo recuperarás en velocidad, fiabilidad y estabilidad. Ademas el API tiene muy pocas probabilidades de cambiar mientras que las paginas web y los elementos HTML cambian frecuentemente y requieren actualizar tu framework de pruebas constantemente.

Autenticarse en sitios de terceros usando el WebDriver en cualquier punto de tus tests incrementa el riesgo de que tus pruebas fallen debido a que aumenta la duración de estas. Por regla general cuanto mas largos sean los tests mas frágiles y poco fiables son.

Las implementaciones del WebDriver que son conformes al W3C también marcan el objecto navigator con la propiedad WebDriver para que los ataques de denegación de servicio (DoS) puedan ser mitigados.

5 - Dependencia entre pruebas

Una idea muy común y equivocada sobre la automatización de pruebas es en lo que respecta al orden de los tests. Tus tests deberían ser capaces de ejecutarse sin tener en cuenta el orden y no depender los unos de los otros para poder finalizarse satisfactoriamente.

6 - Performance testing

Page being translated from English to Spanish. Do you speak Spanish? Help us to translate it by sending us pull requests!

Performance testing using Selenium and WebDriver is generally not advised. Not because it is incapable, but because it is not optimised for the job and you are unlikely to get good results.

It may seem ideal to performance test in the context of the user but a suite of WebDriver tests are subjected to many points of external and internal fragility which are beyond your control; for example browser startup speed, speed of HTTP servers, response of third party servers that host JavaScript or CSS, and the instrumentation penalty of the WebDriver implementation itself. Variation at these points will cause variation in your results. It is difficult to separate the difference between the performance of your website and the performance of external resources, and it is also hard to tell what the performance penalty is for using WebDriver in the browser, especially if you are injecting scripts.

The other potential attraction is “saving time” — carrying out functional and performance tests at the same time. However, functional and performance tests have opposing objectives. To test functionality, a tester may need to be patient and wait for loading, but this will cloud the performance testing results and vice versa.

To improve the performance of your website, you will need to be able to analyse overall performance independent of environment differences, identify poor code practices, breakdown of performance of individual resources (i.e. CSS or JavaScript), in order to know what to improve. There are performance testing tools available that can do this job already, that provide reporting and analysis, and can even make improvement suggestions.

Example (open source) packages to use are: JMeter

7 - Rastreo de enlaces

Usando WebDriver para arañar una web a través de enlaces no es una práctica recomendada, no porque no se pueda hacer, pero porque definitivamente no es la herramienta más ideal. WebDriver necesita tiempo para iniciarse, y puede tomar varios de segundos hasta un minuto dependiendo de cómo se escriba tu prueba, solo para llegar a la página y atravesar el DOM.

En lugar de usar WebDriver para esto, podrías ahorrar un montón de tiempo ejecutando un comando curl, o usando una librería como BeautifulSoup ya que estos métodos no se basan en crear un navegador y navegar a una página. Estás ahorrando toneladas de tiempo al no utilizar WebDriver para esta tarea.

8 - Two Factor Authentication

Page being translated from English to Spanish. Do you speak Spanish? Help us to translate it by sending us pull requests!

Two Factor Authentication (2FA) is an authorization mechanism where a One Time Password (OTP) is generated using “Authenticator” mobile apps such as “Google Authenticator”, “Microsoft Authenticator” etc., or by SMS, e-mail to authenticate. Automating this seamlessly and consistently is a big challenge in Selenium. There are some ways to automate this process. But that will be another layer on top of our Selenium tests and not as secure. So, you should avoid automating 2FA.

There are few options to get around 2FA checks:

  • Disable 2FA for certain Users in the test environment, so that you can use those user credentials in the automation.
  • Disable 2FA in your test environment.
  • Disable 2FA if you login from certain IPs. That way we can configure our test machine IPs to avoid this.