Diferencia entre revisiones de «Contribución a uvlhub - Daniel Galván»

De Wiki de EGC
Saltar a: navegación, buscar
 
(No se muestran 3 ediciones intermedias del mismo usuario)
Línea 10: Línea 10:
  
 
2. En el comando del CLI mencionado con anterioridad, debe haber una opción que permita escoger driver. Si no se escoge ninguno, se utiliza el driver del navegador firefox. En caso contrario, solo se dispondrá de la opción “chrome”.
 
2. En el comando del CLI mencionado con anterioridad, debe haber una opción que permita escoger driver. Si no se escoge ninguno, se utiliza el driver del navegador firefox. En caso contrario, solo se dispondrá de la opción “chrome”.
 
  
 
=Resultados obtenidos=
 
=Resultados obtenidos=
Línea 25: Línea 24:
 
Enlace al video explicativo: https://youtu.be/KSV1k8lpERM  
 
Enlace al video explicativo: https://youtu.be/KSV1k8lpERM  
  
 +
=Tareas realizadas=
 +
 +
A continuación explicaremos qué se ha hecho y cómo. Adelantándonos un poco, se completaron ambas tareas.
 +
 +
==Implementación de “rosemary selenium” en docker==
  
=Tareas realizadas=
+
Para completar esta tarea se ha necesitado utilizar una herramienta externa. En este caso, Selenium-grid. Selenium-grid es una herramienta gratuita que nos permite lanzar pruebas de interfaz de selenium en contenedores de forma dinámica y estática. Para simplificar la situación y porque no estamos ante un conjunto de tests excesivamente grande, se ha implementado de forma estática. Selenium-grid consiste en crear una red de contenedores que serán gestionados con Selenium-hub (el contenedor padre). Para integrar la herramienta he añadido la imagen de Selenium-hub y las imágenes standalone de firefox y chrome. Estas versiones tienen la ventaja de ser ligeras, ya que tienen lo justo para correr el navegador, y el propio navegador en sí. Ambas imágenes crean 1 contenedor, al que llamaremos nodo. Cada nodo depende y es gestionado por Selenium-hub, que se encarga de distribuir la ejecución de los tests. La configuración de los nodos ha sido la recomendada, salvo por un aspecto importante, la variable VNC_NO_PASSWORD. Esta variable nos permitirá entrar a las sesiones de chrome y firefox en las que se ejecutan las pruebas para poder visualizarlas. Se pueden ejecutar en paralelo, pero como consume demasiados recursos he dejado la opción por defecto de 1 sesión. Al levantar el entorno docker, tendremos disponible selenium-hub en el puerto 4444 de nuestro localhost. Cuando ejecutemos pruebas de selenium con pytest o python, uvlhub detectará que estamos en docker observando la variable de entorno WORK_DIR. De esta forma, al inicializar el driver de selenium, uvlhub configurará un driver remoto, para que sea ejecutable por Selenium-hub. No obstante, aunque funcione no es del todo recomendable por el tema de las grabaciones de vídeo, de las cuales hablaremos a continuación. Cuando ejecutamos el comando “rosemary selenium” se comporta de forma parecida a ejecutar pytest solo que hace algo adicional, invocar al nodo de video del driver correspondiente. Esto es más por buena práctica que por necesidad. Funciona igualmente si no lo hiciera pero puede dar problemas en caso de que se quieran grabar vídeos. Esto es por alguna razón que a día de hoy desconozco pues no siempre aparece el mismo error y/o no siempre falla. Hasta donde he descubierto, a veces da fallo en los permisos, y otras da fallo en la comunicación entre nodos. Sea como fuere, tal cual está sigue las pocas recomendaciones que he podido encontrar y ejecuta las pruebas de forma correcta. En cuanto al video, como el hecho de mirar las sesiones en Selenium-hub puede ser tedioso al haber muchos tests ejecutándose muy rápido, he decidido añadir una opción para que se graben los tests. Esto se controla con la opción booleana  –video. Por defecto, es “false”. En caso de ser verdadera, grabarán las pruebas y se guardará el video en “/docker/tmp/videos”. Siempre se generarán 2, uno para firefox y otro para chrome. No obstante, sólo tendrá contenido el del navegador seleccionado (recordemos que por defecto es firefox). Estos videos pueden descargarse, pero no debemos eliminar esos archivos, puesto que en ese caso los nodos no tienen permiso para crearlos y salta un error. Nota: Para ejecutar la opción –video=true deberemos desplegar previamente en local los nodos de video usando docker-compose, de modo que puedan conectarse a los nodos de los navegadores.
 +
 
 +
==Añadir opción de escoger el driver==
 +
 
 +
Para añadir la opción de escoger el driver, lo que hice fue realizar una variable de entorno que por defecto siempre vale “firefox” pero que con rosemary selenium podemos hacer que valga “chrome”. El valor de la variable indica el driver que debe seleccionar uvlhub. Esta opción permite que podamos seleccionar el navegador deseado a nuestro antojo, sin necesidad de preocuparnos por incompatibilidades. En docker la implementación es simétrica sólo que se escoge el driver remoto.
 +
 
 +
==Corregir tests==
 +
 
 +
Realmente no me lo pidieron pero arreglé 2 tests porque había un par de erratas.
 +
 
 +
==Video explicativo==
  
En esta sección se describe todo lo que se ha hecho para completar el trabajo. Es recomendable añadir enlaces a cualquier elemento que se haya generado en el proceso de realización del trabajo. (links a videos, presentaciones, repositorios de código, etc).
+
Aunque tampoco se pidió, realicé un video mostrando el funcionamiento y la implementación donde se habla lo mismo que en este documento: https://youtu.be/KSV1k8lpERM
  
 
=Obstáculos=
 
=Obstáculos=
  
En esta sección se describen todos los problemas que hayan sucedido a lo largo del trabajo así como sus soluciones. También pueden incluirse los cambios o dificultades que hayan puesto en peligro la finalización del trabajo.
+
Como principal problema he tenido la poca documentación que hay sobre Selenium-grid y su uso. Aunque es de gran utilidad, es complejo entender su funcionamiento en un inicio y a veces hay que recurrir a experimentar para entender y a videotutoriales así como leer el código. Teniendo en cuenta que en mi caso personal tengo una agenda muy apretada, fue un poco estresante integrar una herramienta de esta forma.
  
 
=Conclusiones y posibles trabajos futuros=
 
=Conclusiones y posibles trabajos futuros=
  
Conclusiones a las que se ha llegado y posibles extensiones o trabajos futuros
+
Hemos aprendido que es importante documentar para evitar que otras personas tengan tantos problemas a la hora de usar nuestras herramientas. Además, podemos concluir que las tareas se completaron con éxito así como se explicaron de forma audiovisual y por escrito.
 +
 
 +
Como posibles contribuciones futuras podría tenerse en cuenta el hecho de contar con el navegador “edge”, así como implementar “rosemary selenium” en un entorno vagrant.

Revisión actual del 21:41 4 feb 2025

Resumen

En el presente documento se explica y detalla el trabajo realizado para optar a la matrícula de honor en la asignatura Evolución y Gestión de la Configuración.

En mi caso, consiste en realizar una contribución al repositorio uvlhub. Dicha contribución, además de cumplir con los requisitos especificados por el profesor, debe realizarse mediante una Pull Request al repositorio oficial. Los requisitos son los siguientes:

1. Dar la posibilidad de ejecutar los tests de selenium en un entorno docker a través del CLI incluido en el repositorio (rosemary). La idea es que los tests de selenium se ejecuten y puedan visualizarse dentro del entorno docker. En cuanto a la visualización, se deja libre la decisión a tomar (ya sea una pestaña del navegador, un contenedor, etc)

2. En el comando del CLI mencionado con anterioridad, debe haber una opción que permita escoger driver. Si no se escoge ninguno, se utiliza el driver del navegador firefox. En caso contrario, solo se dispondrá de la opción “chrome”.

Resultados obtenidos

Se consiguieron completar todas las tareas y ahora rosemary selenium está soportado en docker.

Además, el comando presenta las 2 nuevas siguientes opciones:

  • –driver, que puede valer “firefox” o “chrome” (por defecto firefox) y sirve para escoger el navegador donde se ejecuten las pruebas.
  • –video, que puede valer “true” o “false” (por defecto false) y sirve para grabar las pruebas de selenium * *

Enlace al proyecto de github: https://github.com/Dangalcan/uvlhub Enlace al video explicativo: https://youtu.be/KSV1k8lpERM

Tareas realizadas

A continuación explicaremos qué se ha hecho y cómo. Adelantándonos un poco, se completaron ambas tareas.

Implementación de “rosemary selenium” en docker

Para completar esta tarea se ha necesitado utilizar una herramienta externa. En este caso, Selenium-grid. Selenium-grid es una herramienta gratuita que nos permite lanzar pruebas de interfaz de selenium en contenedores de forma dinámica y estática. Para simplificar la situación y porque no estamos ante un conjunto de tests excesivamente grande, se ha implementado de forma estática. Selenium-grid consiste en crear una red de contenedores que serán gestionados con Selenium-hub (el contenedor padre). Para integrar la herramienta he añadido la imagen de Selenium-hub y las imágenes standalone de firefox y chrome. Estas versiones tienen la ventaja de ser ligeras, ya que tienen lo justo para correr el navegador, y el propio navegador en sí. Ambas imágenes crean 1 contenedor, al que llamaremos nodo. Cada nodo depende y es gestionado por Selenium-hub, que se encarga de distribuir la ejecución de los tests. La configuración de los nodos ha sido la recomendada, salvo por un aspecto importante, la variable VNC_NO_PASSWORD. Esta variable nos permitirá entrar a las sesiones de chrome y firefox en las que se ejecutan las pruebas para poder visualizarlas. Se pueden ejecutar en paralelo, pero como consume demasiados recursos he dejado la opción por defecto de 1 sesión. Al levantar el entorno docker, tendremos disponible selenium-hub en el puerto 4444 de nuestro localhost. Cuando ejecutemos pruebas de selenium con pytest o python, uvlhub detectará que estamos en docker observando la variable de entorno WORK_DIR. De esta forma, al inicializar el driver de selenium, uvlhub configurará un driver remoto, para que sea ejecutable por Selenium-hub. No obstante, aunque funcione no es del todo recomendable por el tema de las grabaciones de vídeo, de las cuales hablaremos a continuación. Cuando ejecutamos el comando “rosemary selenium” se comporta de forma parecida a ejecutar pytest solo que hace algo adicional, invocar al nodo de video del driver correspondiente. Esto es más por buena práctica que por necesidad. Funciona igualmente si no lo hiciera pero puede dar problemas en caso de que se quieran grabar vídeos. Esto es por alguna razón que a día de hoy desconozco pues no siempre aparece el mismo error y/o no siempre falla. Hasta donde he descubierto, a veces da fallo en los permisos, y otras da fallo en la comunicación entre nodos. Sea como fuere, tal cual está sigue las pocas recomendaciones que he podido encontrar y ejecuta las pruebas de forma correcta. En cuanto al video, como el hecho de mirar las sesiones en Selenium-hub puede ser tedioso al haber muchos tests ejecutándose muy rápido, he decidido añadir una opción para que se graben los tests. Esto se controla con la opción booleana –video. Por defecto, es “false”. En caso de ser verdadera, grabarán las pruebas y se guardará el video en “/docker/tmp/videos”. Siempre se generarán 2, uno para firefox y otro para chrome. No obstante, sólo tendrá contenido el del navegador seleccionado (recordemos que por defecto es firefox). Estos videos pueden descargarse, pero no debemos eliminar esos archivos, puesto que en ese caso los nodos no tienen permiso para crearlos y salta un error. Nota: Para ejecutar la opción –video=true deberemos desplegar previamente en local los nodos de video usando docker-compose, de modo que puedan conectarse a los nodos de los navegadores.

Añadir opción de escoger el driver

Para añadir la opción de escoger el driver, lo que hice fue realizar una variable de entorno que por defecto siempre vale “firefox” pero que con rosemary selenium podemos hacer que valga “chrome”. El valor de la variable indica el driver que debe seleccionar uvlhub. Esta opción permite que podamos seleccionar el navegador deseado a nuestro antojo, sin necesidad de preocuparnos por incompatibilidades. En docker la implementación es simétrica sólo que se escoge el driver remoto.

Corregir tests

Realmente no me lo pidieron pero arreglé 2 tests porque había un par de erratas.

Video explicativo

Aunque tampoco se pidió, realicé un video mostrando el funcionamiento y la implementación donde se habla lo mismo que en este documento: https://youtu.be/KSV1k8lpERM

Obstáculos

Como principal problema he tenido la poca documentación que hay sobre Selenium-grid y su uso. Aunque es de gran utilidad, es complejo entender su funcionamiento en un inicio y a veces hay que recurrir a experimentar para entender y a videotutoriales así como leer el código. Teniendo en cuenta que en mi caso personal tengo una agenda muy apretada, fue un poco estresante integrar una herramienta de esta forma.

Conclusiones y posibles trabajos futuros

Hemos aprendido que es importante documentar para evitar que otras personas tengan tantos problemas a la hora de usar nuestras herramientas. Además, podemos concluir que las tareas se completaron con éxito así como se explicaron de forma audiovisual y por escrito.

Como posibles contribuciones futuras podría tenerse en cuenta el hecho de contar con el navegador “edge”, así como implementar “rosemary selenium” en un entorno vagrant.