Monitorización Sintética y Pruebas de Extremo a Extremo - Dos Caras de la Misma Moneda

Rate this content
Bookmark
Slides

En los últimos años, se ha puesto gran énfasis en desplazar las pruebas hacia la izquierda, es decir, hacia etapas más tempranas del ciclo de desarrollo de software. Es genial que la aparición de tendencias como las pruebas de extremo a extremo nos haya permitido validar el flujo de trabajo del usuario de manera más temprana. Sin embargo, esto no elimina la necesidad de monitorear este flujo de trabajo en un sistema de producción en vivo. He observado que la segregación de los equipos de desarrollo y soporte lleva a que ambos equipos utilicen diferentes herramientas para construir automatizaciones similares que simplemente apuntan a diferentes entornos del mismo software.
Al unir fuerzas, podemos construir scripts automatizados que se pueden utilizar tanto para la monitorización en producción como para las pruebas dentro de CI. En esta charla, discutiré las causas de esta división cultural y por qué es necesario que esto cambie para poder desplazar las pruebas de usuario tanto hacia la izquierda como hacia la derecha. Además, mostraré cómo se puede lograr esto utilizando Playwright y Elastic Synthetics y también hablaré sobre los desafíos a los que te puedes enfrentar al desplazar las pruebas hacia la izquierda y hacia la derecha.

9 min
06 Jun, 2023

Video Summary and Transcription

Carly Richards analiza los desafíos de utilizar diferentes herramientas para la monitorización sintética y las pruebas de extremo a extremo, enfatizando la necesidad de un enfoque unificado con Playwright y Elastic Synthetics. La API de Playwright y Elastic Synthetics se pueden utilizar juntas para crear pruebas y herramientas de monitorización, asegurando una experiencia de usuario consistente y documentando las características de la aplicación. Al reunir a los equipos de desarrollo y SRE y utilizar una herramienta común, se puede mejorar la colaboración y la identificación de defectos.

Available in English

1. Desafíos de las herramientas y la necesidad de unificación

Short description:

En esta parte, Carly Richards analiza los desafíos de utilizar diferentes herramientas para el monitoreo sintético y las pruebas de extremo a extremo. Explica cómo la falta de colaboración entre los equipos de desarrollo y operaciones, las prioridades diferentes y el uso de diferentes herramientas pueden obstaculizar los esfuerzos de automatización. Carly enfatiza la necesidad de un enfoque unificado e introduce playwright y Elastic Synthetics como solución. Al utilizar estas herramientas, los equipos pueden crear recorridos programados que sirven tanto como pruebas como herramientas de monitoreo, asegurando una experiencia de usuario consistente y documentando las características de la aplicación. Carly también proporciona una descripción general del proceso de implementación y destaca la importancia de mantener los monitores dentro de una estructura de proyecto.

Hola a todos. Es genial verlos en el React Summit. Mi nombre es Carly Richards, soy una defensora del desarrollo en Elastic. Y quiero hablar sobre el monitoreo sintético y las pruebas de extremo a extremo. Tal vez se pregunten por qué estas cosas pueden parecer construcciones totalmente diferentes. Pero a pesar de la aparición de DevOps y las prácticas de SRE, y de tratar de unir los flujos de trabajo personalizados, descubro que, por diversas razones, todavía estamos utilizando diferentes herramientas para tratar de lograr niveles de automatización bastante similares, aunque en diferentes puntos del ciclo de desarrollo.

Voy a hablar sobre mis propias experiencias y por qué creo que esto sucede. Y luego mostraré cómo podemos unirnos mediante un tooling común utilizando pruebas de extremo a extremo integradas en un tooling de monitoreo sintético, para permitirnos básicamente hacer ambas cosas utilizando los mismos recorridos programados. Así que solía trabajar en un banco antes de unirme a Elastic, y durante la mayor parte de ese tiempo, descubrí que el desarrollo y las operaciones no estaban tan unidos como nos gustaría decir. Básicamente eran facciones en guerra con intereses en competencia, y las mejores prácticas emergentes de SRE y DevOps que surgían en el espacio de la observabilidad a menudo eran adoptadas por la gestión de producción, pero nunca permeaban fácilmente hacia el lado del desarrollo. Y se necesitó mucha persuasión para que eso sucediera. Y honestamente creo que eso se debió a tres razones clave que, lamentablemente, creo que todavía existen en cierta medida hoy en día. La primera es que a menudo tenemos el desarrollo y SRE como departamentos separados o equipos separados, en lugar de ser parte de un equipo multidisciplinario. Y con los departamentos separados y agendas en competencia, la falta de comunicación y empatía tiende a acumularse, lo que puede ser un gran problema porque hace que cada grupo sienta que cuando alguien propone la idea de colaborar juntos, estamos lanzando cosas al otro lado de la cerca para que el otro las recoja y rompa el flujo y básicamente cuestione la dirección en la que sabíamos que debíamos construir como desarrolladores o como SRE. La segunda es que a menudo no hay una priorización común entre estos dos grupos. SRE a menudo puede encontrar defectos menores o tener ideas para la automatización o mejoras en el ecosistema de la aplicación pero con frecuencia se les da una prioridad baja y en su lugar, un propietario del producto presiona por nuevas características para los usuarios que los desarrolladores estarán encantados de construir y nunca abordamos este equilibrio. Y el último desafío que también he visto de primera mano es que a menudo los equipos de desarrollo y producción utilizan diferentes herramientas para lograr objetivos similares. Así que en mi último trabajo en el banco, estábamos utilizando activamente cypress para desarrollar pruebas de extremo a extremo mientras que los colegas de SRE estaban escribiendo automatizaciones similares en Selenium porque se integraba en su plataforma de observabilidad y podían usarlo para monitoreo periódico y verificaciones en la aplicación de producción. Y eso significaba que no podíamos usar realmente las pruebas de extremo a extremo en producción sin que alguno de nosotros cambiara a una nueva tooling. Y la realidad es que las pruebas de extremo a extremo utilizando marcos de automatización para validar el recorrido del usuario a través de pruebas automatizadas y el monitoreo sintético, donde ejecutamos scripts periódicos para verificar la accessibility o los puntos finales o la capacidad de lograr el comportamiento del usuario para asegurarnos de que siga funcionando correctamente, son efectivamente dos caras de la misma moneda. Y si nos unimos mediante un tooling común, podemos utilizar estos mismos scripts no solo como pruebas y herramientas de monitoreo en las mismas suites de aplicaciones en diferentes entornos, sino que también podemos utilizarlos como una forma común de documentar el recorrido del usuario y cómo esperamos que los usuarios utilicen las características de la aplicación. Así que podemos hacer eso utilizando playwright y Elastic Synthetics. La forma en que esto funciona como verán en gris a través de cada uno de los cuadros es que tendremos archivos de recorrido en JavaScript y TypeScript que básicamente utilizarán playwright para automatizar esas interacciones y ejecutarlas localmente como pruebas de extremo a extremo contra una aplicación web que se esté ejecutando localmente. Luego, a través de la revisión de pares, podemos ejecutar los mismos monitores como pruebas de extremo a extremo dentro del pipeline de CI de GitHub o cualquier otro proveedor de CI que estén utilizando. Una vez que llegamos a la etapa de implementación de nuestra aplicación, podemos enviar estos mismos monitores utilizando nuestra propia clave de API al lugar correspondiente, ya sea la ubicación específica de Elastic o nuestra propia ubicación privada en ejecución, para hacer el monitoreo en lugar de la aplicación web de producción, que luego almacenará los resultados dentro de Elasticsearch y pondrá a disposición los paneles en Kibana para que podamos ver qué está sucediendo. Entonces, ¿cómo comenzamos con esto? Bueno, necesitamos crear un proyecto para alojar estos monitores para que puedan mantenerse dentro de el control de origen utilizando ambas partes. La forma más fácil de hacerlo es utilizando el asistente de inicialización después de instalar el envoltorio de Elastic Synthetics Playwright a través de NPM. Le dará una estructura de proyecto de muestra que se verá así, e incluirá configuraciones sintéticas para la configuración específica del proyecto y algunos monitores de ejemplo, incluidos los recorridos en TypeScript que pueden ver allí en la carpeta de recorridos. Luego podemos escribir nuestras propias pruebas de comportamiento basándonos en los ejemplos utilizando Elastic Synthetics. Verán aquí en la parte superior que el objeto de página que es el objeto de página de playwright se expone dentro de nuestro recorrido y también dentro de cada palo.

2. Uso de la API de Playwright y Elastic Synthetics

Short description:

Podemos utilizar la API de Playwright para localizar elementos, realizar acciones y realizar afirmaciones para garantizar los resultados esperados. Estas pruebas se pueden ejecutar localmente y en tuberías de CI, y las mismas definiciones se pueden implementar en producción utilizando Elastic Synthetics. El equipo de SRE puede monitorear el estado y realizar un seguimiento del rendimiento a lo largo del tiempo. Al unir los equipos de desarrollo y SRE y utilizar una herramienta común, podemos colaborar, identificar defectos y construir mejores aplicaciones. ¡Gracias por asistir a React Summit!

Y podemos hacer uso de la API de Playwright para realizar acciones como localizar elementos mediante el selector CSS, que puedes ver en la línea 16, utilizando los diversos atributos auxiliares introducidos en las versiones 2017 y posteriores, como obtener por ID de prueba. Podemos realizar clics y acciones que un usuario haría en estos elementos HTML apropiados y luego podemos realizar diversas afirmaciones para ver que el resultado apropiado se muestra allí. Y luego podemos ejecutar estas pruebas localmente y asegurarnos de que todos los cambios asociados con nuestra nueva función se aprueben. Luego podemos ejecutar las mismas pruebas en nuestras tuberías de CI y luego podemos implementar esas mismas definiciones en producción en la ubicación de Elastic Synthetics que le permitirá ejecutar esas mismas pruebas como monitores en su aplicación de producción.

Luego, el equipo de SRE puede monitorear el estado. Pueden ver los pings básicos, pueden ver como se destaca en el fondo de estas tarjetas cuál ha sido la duración a lo largo del tiempo utilizando el gráfico en el fondo. Luego, cuando las cosas salen mal, podemos ver los pasos individuales, podemos ver qué expectativas o errores particulares ocurrieron y luego podemos hacer cosas inteligentes como tener alertas o detecciones de anomalías para intentar detectar si hay una degradación en el rendimiento si estas pruebas particulares están tardando más según nuestras tendencias. Para mí, DevOps siempre ha significado unir a las facciones de desarrollo y SRE. Necesitamos dejar atrás esa carga cultural que ha estado presente durante tanto tiempo y trabajar juntos, y si usamos una herramienta común, hay algunos grandes beneficios en términos de documentar el recorrido del usuario, colaborar juntos, detectar defectos en las pruebas y en producción y, en general, construir mejores aplicaciones para los usuarios. Así que muchas gracias, ha sido genial hablar aquí en React Summit. Espero poder encontrarte en la conferencia y, si no, no dudes en consultar el ejemplo de código en el código QR de la pantalla o también puedes contactarme con cualquier pregunta en currentlyellrichmond. ¡Adiós!

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Top Content
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2022TestJS Summit 2022
20 min
Testing Web Applications with Playwright
Top Content
Testing is hard, testing takes time to learn and to write, and time is money. As developers we want to test. We know we should but we don't have time. So how can we get more developers to do testing? We can create better tools.Let me introduce you to Playwright - Reliable end-to-end cross browser testing for modern web apps, by Microsoft and fully open source. Playwright's codegen generates tests for you in JavaScript, TypeScript, Dot Net, Java or Python. Now you really have no excuses. It's time to play your tests wright.
TestJS Summit 2023TestJS Summit 2023
21 min
Everyone Can Easily Write Tests
Let’s take a look at how Playwright can help you get your end to end tests written with tools like Codegen that generate tests on user interaction. Let’s explore UI mode for a better developer experience and then go over some tips to make sure you don’t have flakey tests. Then let’s talk about how to get your tests up and running on CI, debugging on CI and scaling using shards.
TestJS Summit 2022TestJS Summit 2022
21 min
Tiny Tests, Large Results
Yes, Big things do come in small packages. For example, isn’t a unit test’s speed, feedback, and reliability fantastic? Did you know we can also have fast, focused, and reliable feedback from our functional e2e tests? Atomic e2e tests are those that are targeted and focused. They’re tiny in size but large in their impact. This tutorial will teach you how to create atomic e2e tests with several code examples. First, we will use Cypress.io to authenticate by setting a cookie. Instead of using a UI. Second, we will use Cypress.io to set a JSON Web Token for authentication. Join me, and let’s write tiny tests for large results.
TestJS Summit 2022TestJS Summit 2022
17 min
Testing Mail Service With Playwright
Top Content
We send emails to our users - account verification and newsletters. We allow the user to contact us by sending an email via inbuild form. Do we? Does the user receive an account verification email or exactly what notification they signed up for? We can cover this functionality as part of E2E tests: get an email and open it to check what is in it. We will need Playwright and a fake SMTP server to capture emails sent by the app.
TestJS Summit 2022TestJS Summit 2022
21 min
E2E Tests for Web3 Applications
Top Content
We will go through a brief explanation of what is Web3 and the architecture of a web3 application. Then we will talk about how to end-to-end test, its challenges, some test tools that are available, and a demo using cypress and metamask.Agenda: What is Web3; The Architecture of a Web3 Application; Web3 E2E Tests Introduction; Web3 E2E Tests Challenges; E2E Test Tools; Demo.

Workshops on related topic

React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
TestJS Summit 2023TestJS Summit 2023
89 min
Building out a meaningful test suite that's not all E2E
Workshop
We're all taught to follow the Testing Pyramid but the reality is that we build out the Testing Christmas Tree. In this workshop, David will talk you through how to break down projects and put the tests where they need to be. By the end of the workshop you will be able to update your projects so that anyone and everyone can start contributing and truly living up to "Quality is everyone job".
He will walk you through:- Component Testing- API Testing- Visual Regression Testing- A11Y testing
He will also talk you through how to get these all setup in your CI/CD pipeline so that you can get shorter and faster feedback loops.
TestJS Summit 2021TestJS Summit 2021
146 min
Live e2e test debugging for a distributed serverless application
WorkshopFree
In this workshop, we will be building a testing environment for a pre-built application, then we will write and automate end-to-end tests for our serverless application. And in the final step, we will demonstrate how easy it is to understand the root cause of an erroneous test using distributed testing and how to debug it in our CI/CD pipeline with Thundra Foresight.

Table of contents:
- How to set up and test your cloud infrastructure
- How to write and automate end-to-end tests for your serverless workloads
- How to debug, trace, and troubleshot test failures with Thundra Foresight in your CI/CD pipelines
TestJS Summit - January, 2021TestJS Summit - January, 2021
127 min
Uniform Browser Automation Infrastructure
Workshop
In this workshop, I will show you how to quickly deploy and use browser automation infrastructure with Moon solution. We will start deploying everything on your workstation and will soon be able to run Selenium, Playwright and Puppeteer tests in parallel in the same cluster. Then I will demonstrate how to easily deliver the same experience for your team using a remote cluster in the cloud platform.