How Guru’s Engineers Use Cypress for Better Burn Testing
¿Necesitas una mejor manera de manejar las pruebas de carga? Dos de nuestros ingenieros de frontend han encontrado una forma de usar Cypress para mejorar la forma en que manejan el control de calidad.
¡Nosotros nos dedicamos a compartir conocimiento en Guru, y cuando descubrimos algo nuevo y útil, queremos que el mundo lo sepa! Nuestro equipo de ingeniería utiliza Cypress en su proceso de pruebas y control de calidad. Han descubierto una nueva forma de ayudar a ejecutar mejores pruebas de carga, y quieren compartir su nuevo y mejorado proceso con otros ingenieros y testers.
Durante el último año, nos hemos estado enfocando en aumentar nuestra cobertura de pruebas, específicamente, pruebas de extremo a extremo que aseguran que diferentes partes de los flujos de nuestra producto funcionen correctamente mientras hacemos actualizaciones de código. Para este tipo de pruebas, aprovechamos una herramienta llamada Cypress que simula el comportamiento del usuario con nuestra aplicación web y la extensión de Google Chrome. Este conjunto de pruebas se ejecuta en cada solicitud de extracción para asegurarse de que el nuevo código no esté rompiendo cosas en nuestra interfaz de usuario. También queremos bloquear lanzamientos si nuestro conjunto de Cypress falla en nuestra rama de producción.
Lo que buscamos en pruebas tradicionales
Un problema con el que hemos lidiado es ver algunas de nuestras pruebas fallar, pero no por razones relacionadas con la UI o el código. Entonces, ¿cómo nos ayuda Cypress en estos casos? Hacemos que Cypress actúe como un usuario cuyo comportamiento podemos definir. Hay varias variables que podrían llevar a Cypress a informarnos que hay un fallo, pero desde la perspectiva del usuario, nada parece estar mal.
Por ejemplo, podría haber una prueba que diga: “Ve a esta parte de la aplicación web > Agregar una nueva tarjeta Guru > Esperar ver un estado posterior a la creación”. Si el estado de carga de crear una tarjeta se tarda un milisegundo demasiado y Cypress comienza a buscar el estado posterior a la creación antes de que esté allí, esta prueba podría fallar (la mayoría de las veces, sin embargo, esta prueba pasará). Si pasa una vez en una solicitud de extracción, podemos fusionar código que podría fallar a veces. Pero no sabremos si lo hace; una prueba aprobada no garantiza que el código sea correcto.
Este tipo de situación reduce la confiabilidad de nuestra cobertura de pruebas. Como resultado, cuando aparece un fallo en una prueba en nuestra cadena de implementación, necesitamos verificar si es un problema con la UI o con la prueba. Para solucionar esto, comenzamos a pensar en formas en las que podríamos detectar si una prueba podría fallar antes de que pase a nuestra rama de código de producción.
Cómo ayuda la prueba de carga
Introduciendo la prueba de carga. La prueba de carga es un proceso utilizado para probar algo en condiciones más rigurosas o extremas. También se le llama a veces prueba de estrés o prueba de carga, dependiendo del método o el área específica que se está probando.
En Guru, utilizamos la prueba de carga como parte de nuestro conjunto de Cypress para cualquier prueba nueva o modificada que se añada a nuestra base de código. Antes de que estas pruebas puedan ser fusionadas, las ejecutamos varias veces seguidas y todas deben pasar para poder avanzar al siguiente paso en nuestra tubería de construcción de CircleCI.
Este paso ocurre inmediatamente antes de ejecutar todo el conjunto de pruebas de Cypress. La ventaja de este orden es que si nuestro paso de prueba de carga produce un fallo, podemos marcar toda la verificación como un fallo temprano. Saltar el resto del conjunto nos permite ahorrar tiempo y reducir el número de ciclos que se pueden necesitar para garantizar que las pruebas recién introducidas sean tan confiables y tolerantes a fallos como necesitamos que sean.
Para encontrar los archivos que buscamos, utilizamos git diff en la rama actual y suministramos la salida como parámetro a una herramienta llamada cypress-repeat que nos permite ejecutar esas pruebas un número especificado de veces, añadiendo efectivamente la prueba de carga como un paso en nuestro conjunto de pruebas de extremo a extremo.
El resultado
Hacer este ajuste en nuestros planes de prueba ha tenido resultados positivos bastante sólidos. Para nosotros, añadir pruebas de carga puede reducir el tiempo que tardamos en encontrar pruebas poco confiables en hasta 30 minutos. También mejora el tiempo de respuesta para añadir nueva funcionalidad. Dado que las pruebas recién añadidas ahora se ejecutan primero, nos permiten verificar la estabilidad antes de continuar con el resto del proceso de construcción.
En general, nuestro continuo enfoque en hacer que nuestros procesos de prueba sean más eficientes y robustos aumenta la confianza de todo el equipo de ingeniería en enviar nuevas funciones rápidamente. Estamos solucionando bugs más rápido y haciendo que sea más fácil trabajar a través de todos nuestros códigos. Esperamos que esta publicación ayude a otros usuarios de Cypress a crear mejores pruebas y que equipos enteros construyan de manera más eficiente.
¡Nosotros nos dedicamos a compartir conocimiento en Guru, y cuando descubrimos algo nuevo y útil, queremos que el mundo lo sepa! Nuestro equipo de ingeniería utiliza Cypress en su proceso de pruebas y control de calidad. Han descubierto una nueva forma de ayudar a ejecutar mejores pruebas de carga, y quieren compartir su nuevo y mejorado proceso con otros ingenieros y testers.
Durante el último año, nos hemos estado enfocando en aumentar nuestra cobertura de pruebas, específicamente, pruebas de extremo a extremo que aseguran que diferentes partes de los flujos de nuestra producto funcionen correctamente mientras hacemos actualizaciones de código. Para este tipo de pruebas, aprovechamos una herramienta llamada Cypress que simula el comportamiento del usuario con nuestra aplicación web y la extensión de Google Chrome. Este conjunto de pruebas se ejecuta en cada solicitud de extracción para asegurarse de que el nuevo código no esté rompiendo cosas en nuestra interfaz de usuario. También queremos bloquear lanzamientos si nuestro conjunto de Cypress falla en nuestra rama de producción.
Lo que buscamos en pruebas tradicionales
Un problema con el que hemos lidiado es ver algunas de nuestras pruebas fallar, pero no por razones relacionadas con la UI o el código. Entonces, ¿cómo nos ayuda Cypress en estos casos? Hacemos que Cypress actúe como un usuario cuyo comportamiento podemos definir. Hay varias variables que podrían llevar a Cypress a informarnos que hay un fallo, pero desde la perspectiva del usuario, nada parece estar mal.
Por ejemplo, podría haber una prueba que diga: “Ve a esta parte de la aplicación web > Agregar una nueva tarjeta Guru > Esperar ver un estado posterior a la creación”. Si el estado de carga de crear una tarjeta se tarda un milisegundo demasiado y Cypress comienza a buscar el estado posterior a la creación antes de que esté allí, esta prueba podría fallar (la mayoría de las veces, sin embargo, esta prueba pasará). Si pasa una vez en una solicitud de extracción, podemos fusionar código que podría fallar a veces. Pero no sabremos si lo hace; una prueba aprobada no garantiza que el código sea correcto.
Este tipo de situación reduce la confiabilidad de nuestra cobertura de pruebas. Como resultado, cuando aparece un fallo en una prueba en nuestra cadena de implementación, necesitamos verificar si es un problema con la UI o con la prueba. Para solucionar esto, comenzamos a pensar en formas en las que podríamos detectar si una prueba podría fallar antes de que pase a nuestra rama de código de producción.
Cómo ayuda la prueba de carga
Introduciendo la prueba de carga. La prueba de carga es un proceso utilizado para probar algo en condiciones más rigurosas o extremas. También se le llama a veces prueba de estrés o prueba de carga, dependiendo del método o el área específica que se está probando.
En Guru, utilizamos la prueba de carga como parte de nuestro conjunto de Cypress para cualquier prueba nueva o modificada que se añada a nuestra base de código. Antes de que estas pruebas puedan ser fusionadas, las ejecutamos varias veces seguidas y todas deben pasar para poder avanzar al siguiente paso en nuestra tubería de construcción de CircleCI.
Este paso ocurre inmediatamente antes de ejecutar todo el conjunto de pruebas de Cypress. La ventaja de este orden es que si nuestro paso de prueba de carga produce un fallo, podemos marcar toda la verificación como un fallo temprano. Saltar el resto del conjunto nos permite ahorrar tiempo y reducir el número de ciclos que se pueden necesitar para garantizar que las pruebas recién introducidas sean tan confiables y tolerantes a fallos como necesitamos que sean.
Para encontrar los archivos que buscamos, utilizamos git diff en la rama actual y suministramos la salida como parámetro a una herramienta llamada cypress-repeat que nos permite ejecutar esas pruebas un número especificado de veces, añadiendo efectivamente la prueba de carga como un paso en nuestro conjunto de pruebas de extremo a extremo.
El resultado
Hacer este ajuste en nuestros planes de prueba ha tenido resultados positivos bastante sólidos. Para nosotros, añadir pruebas de carga puede reducir el tiempo que tardamos en encontrar pruebas poco confiables en hasta 30 minutos. También mejora el tiempo de respuesta para añadir nueva funcionalidad. Dado que las pruebas recién añadidas ahora se ejecutan primero, nos permiten verificar la estabilidad antes de continuar con el resto del proceso de construcción.
En general, nuestro continuo enfoque en hacer que nuestros procesos de prueba sean más eficientes y robustos aumenta la confianza de todo el equipo de ingeniería en enviar nuevas funciones rápidamente. Estamos solucionando bugs más rápido y haciendo que sea más fácil trabajar a través de todos nuestros códigos. Esperamos que esta publicación ayude a otros usuarios de Cypress a crear mejores pruebas y que equipos enteros construyan de manera más eficiente.
Experimenta el poder de la plataforma Guru de primera mano: realiza nuestro recorrido interactivo por el producto
