Zen y el Arte de Pruebas de Componentes de UI

Un breve paseo por el camino de la memoria. Este soy yo. Aquí acabo de graduarme en mi masterclass de programación que fue en el Ejército Israelí, la masterclass de Mammran. Aprendimos muchas cosas. Lo único que no aprendimos es testing. Y esto es porque el año es 1990. Y este es el mismo año en que se publicó este libro por Mycom. Y está hablando de tener éxito con Agile. Y si te sumerges en este libro, encontrarías este diagrama. Este es el pirámide original de automation de pruebas. Habla de tres niveles. Unidad, servicio y UI. Y te das cuenta de que la UI está en la parte superior. Más tarde, esto evolucionó hacia la pirámide de testing, que todos conocemos. Y el nombre cambió. Todavía hablamos de prueba de unidad. Pero también hablamos de integración. Y la prueba de UI se ha convertido en prueba de extremo a extremo. Y esto es realmente cierto, porque esto es lo que sucedió durante muchos años. Veríamos la prueba de extremo a extremo como un sinónimo

Y lo primero, el primer principio, es que quiero hablar sobre aislamientos. Esta es una página, lo que una página web, una aplicación web parecía en los años 90. Como puedes ver, es bastante simple y es solo una página. Pero luego, más adelante, y estamos hablando aquí sobre 2015, más o menos empezamos a trabajar de una manera completamente diferente al construir nuestra aplicación web. Empezamos a hablar sobre componentes. Esto es AngularJS, como dije, en diciembre de 2015. Están hablando sobre entender los componentes cuando desarrollas una aplicación Angular. Y esto es de junio de 2016. Este es el commit real que se hizo en el readme de React. Y también empezó a hablar sobre lo que significa ser basado en componentes. Habla sobre la construcción de componentes encapsulados que gestionan su propio estado y luego los componen en UIs más complejas. Y todavía vemos a los componentes como una especie de ladrillos de lego. Tienes un componente separado de la exhibición. Cada uno con su propia funcionalidad y luego vas y los construyes en UIs más grandes como barcos, casas, o incluso un servidor de rack de motor de búsqueda que fue construido con lego.

Hoy cuando hablamos del marco moderno para construir UI como Angular, React, Vue, Solid, Svelte, etc., todos están construidos sobre el principio de basado en componentes. Y esto es lo que te permiten hacer los componentes. Te permiten dividir la UI en piezas independientes y reutilizables y puedes pensar en cada pieza de forma aislada. Y cuando dices pensar, no se trata solo de pensar, también se trata de construirlo de forma aislada y probarlo en aislamiento. En este ejemplo aquí, podemos ver que esta es una aplicación CodeWe, una aplicación de demostración que está construida en múltiples lenguajes y frameworks. Puedes encontrar casi cualquier framework que te gustaría. Y puedes ver aquí que en realidad está utilizando el mismo componente de una vista previa de artículo tanto en el feed global como en MyPost. Y esto implica que si quiero probar la funcionalidad de este componente, no necesito ir a la página específica del feed global como lo haría en la prueba de extremo a extremo o iniciar sesión e ir a MyPost como lo haría en la página de MyPost. En realidad puedo aislar este componente, ponerlo por separado. Y como vemos aquí, este es el mismo componente, pero la página solo muestra este componente. Esto está utilizando Storybook. Storybook es una gran herramienta para demostrar y mostrar y exhibir componentes en aislamiento.

Aquí puedo ver que esto es de la misma aplicación. Tomé el componente del editor. Esto es cuando quiero componer un artículo. Y puedes ver en el mismo Storybook, tengo este componente de forma aislada. Y una vez que tengo este componente, esto es acercándome al componente, realmente puedo probar que funciona correctamente, independientemente de en qué página se coloque. Así que puedo verificar aquí que tengo mis likes, que puedo hacer clic en ellos. Puedo verificar que el read es en realidad la referencia a la correcta URL. Puedo probar aquí que estoy mostrando las etiquetas correctas, que están en el orden correcto si hay una regla específica para el orden y así sucesivamente. Así que el punto número uno es que puedo probar mi componente en aislamiento. La otra cosa cuando hablo con la gente sobre los componentes de UI, ¿cómo los pruebas? Ellos generalmente dirían algo. Sí, quiero probar los data, quiero probar la interacción del usuario, quiero probar el diseño, quiero probar que genera eventos y usarían herramientas como Jest o V-test para probar mis componentes. Lo importante a entender cuando estamos usando Jest es que generalmente no estamos usando un navegador real sino lo que se llama un DOM simulado. El de arriba es muy popular. También hay uno más nuevo que se llama HappyDOM. ¿Qué significa trabajar con un DOM falso? Cuando estamos construyendo nuestra aplicación web, independientemente de si es un componente o no, bajo el capó, todavía necesita llamar al DOM, el modelo de objeto de documento, que es el núcleo de cómo funciona el navegador. Y cada vez que construimos un componente, y realmente no importa qué frameworks usemos, al final del día, necesitará llamar a las APIs del DOM para renderizar el componente. Podríamos envolverlo en algún JSX o TSX o plantillas de Angular o lo que sea, pero bajo el capó, todavía necesita ser traducido a selector de consulta, crear elemento, establecer atributo, agregar escuchador de eventos, y todas las API que conocemos en el DOM. Y generalmente estas API son proporcionadas por nuestro navegador. El navegador se ajusta al estándar de cómo funcionan las API del DOM y las usaríamos. Pero lo que la gente decide hacer con un DOM falso es en realidad tomar otros motores que pueden ejecutar JavaScript, y en su mayoría esto es Node.js. Nosotros tenemos algunos otros motores hoy en día, pero Node.js es definitivamente el más popular. Y construimos todas las API que el navegador tiene pero en Node.js. Pero lo importante a entender es que sí, falsificamos las API, pero realmente no hacemos lo que hace el navegador. Y esto significa principalmente que no estamos renderizando realmente el componente porque esto sigue siendo falso. No sabe cómo renderizar componentes. Y lo que la gente dice muy a menudo es que cuando estás testing tu componente de esta manera, se siente un poco como jugar a qué hay en la caja. Porque el componente, este es un componente de UI, tiene un lado visual, pero realmente no lo estamos viendo. Así que estamos intentando, cuando estamos testing, intentar adivinar qué hay dentro. Estamos usando herramientas como enzyme o testing library y así sucesivamente. Pero aún así, esto es mucho de juego de adivinanzas.

Y especialmente cuando estamos trabajando con componentes de UI advanced, componentes de UI que tienen cosas como medios advanced, que tienen lienzos y gráficos que se están animando. Y tenemos muchas microinteracciones y también tenemos muchos gestos que necesitamos soportar, como arrastrar y soltar o hacer zoom y así sucesivamente. Aquí es donde la simulación de las APIs se queda realmente corta. Y a veces es muy difícil y estás intentando hacer que tu DOM falso, navegador falso funcione como un navegador y inviertes mucho tiempo y es realmente frustrante en la prueba. Porque al final del día, es muy simple. Cuando tenemos componentes de UI, queremos probarlos en un navegador real. Y esto significa que realmente renderizará nuestro componente. No solo vamos a probar que tenemos la clase CSS correcta, sino que también queremos probar que el CSS está construyendo nuestro componente correctamente y que se visualiza correctamente. Queremos hablar sobre la llamada a la red que a veces es diferente cuando estamos trabajando con el navegador. Queremos probar la interacción, todos los gestos que mencioné, y también el tiempo adecuado. Cuando estamos trabajando con un mock, normalmente no se ajusta al tiempo que realmente tiene el navegador, o al evento pseudo y así sucesivamente. Si hay efectos secundarios, de nuevo, el evento pseudo es un ejemplo, como el cambio de entrada y así sucesivamente, queremos asegurarnos de que se dispara correctamente, y no nosotros disparándolo manualmente, y al final del día podríamos querer mirar realmente el componente y hacer una captura de pantalla y hacer una prueba de regresión visual y asegurarnos de que se vea exactamente como esperábamos que se viera. Y a lo largo de los años, hay muchas herramientas que apoyan este tipo de automation del navegador. Normalmente son sinónimo de pruebas de extremo a extremo, de nuevo desde este enfoque, se dice que la UI solo se prueba en pruebas de extremo a extremo. Tenemos Selenium desde hace 20 años, tenemos WebDriver.io que es muy popular. Estos no son los únicos. Y recientemente, en los últimos años, tenemos herramientas más modernas como Puppeteer y Cypress, y probablemente la última y mejor adición es PlayWrite junto con la versión más nueva de Selenium. Y discutiremos cómo son diferentes. Entonces, para lograr nuestro segundo punto final, queremos asegurarnos de que probamos en un navegador real. El tercer punto para hacer esta testing zen y divertida, queremos que sea eficiente. Queremos asegurarnos de que escribimos la prueba y que se ejecutan rápido y fácil de cambiar y fácil de hacer todas las cosas que necesitamos encima de ellas. Y para entender cómo podemos lograr la eficiencia, vamos a acercarnos un poco al navegador. Esto es lo que conocemos como el navegador, pero en realidad es el proceso de renderizado del navegador. Esto es lo que vemos en la pantalla. Tiene JavaScript, y ahora también tiene workers. Pero bajo el capó, el navegador tiene muchos otros procesos como los que ves aquí. Tenemos el proceso del service worker. Tenemos el proceso de red. Tenemos todos los procesos del navegador, cosas que controlan la security, la ubicación, las entradas, obteniendo la entrada del sistema operativo y enviándola al navegador, y muchas otras partes. La primera generación, o lo que era común para probar los procesos,

La segunda generación son esos navegadores falsos de los que hablé, que todavía son populares, que básicamente dicen que no tenemos nada de esto, solo estamos escribiendo en Node algunas de las pruebas que queremos. Y el enfoque más moderno es tener, lo que llamamos, una automatización fuera de proceso. Todas estas partes del navegador son realmente accesibles a través de APIs. Comenzó como un protocolo de desarrollador de Chrome. Y escribimos un programa externo que en realidad está controlando todas estas partes. Esto fue iniciado con Puppeteer en Google. Esto es lo que hicieron como una herramienta genérica que está escrita en Node.js y está controlando nuestro navegador a través de este protocolo. Y más tarde, el mismo equipo que estaba construyendo Puppeteer en Google se mudó a Microsoft y construyó Playwright. Y extendieron este protocolo, no solo para la automatización genérica del navegador, sino que realmente se centraron en lo que está disponible, lo que se requiere para las testing, como si tuviéramos una animación, queremos esperar hasta que se estabilice y solo entonces quiero hacer clic en el botón. Muchos de los problemas existían con todas las herramientas como Selenium. ¿Qué obtenemos con la automatización del navegador fuera de proceso? ¿Por qué es tan bueno? En primer lugar, tenemos acceso completo al sistema de archivos porque esto es externo y no se está ejecutando en el navegador. Esto se está ejecutando en nuestra máquina. Por ejemplo, en Node.js, podemos acceder a cualquier archivo. Podemos acceder a la prueba donde queramos. Podemos ejecutar en paralelo. De nuevo, este es un programa separado. No tenemos ningún problema para ejecutarlo varias veces tantas como sea necesario. Multi-idioma, no tiene que ser JavaScript. Esta automation que está controlando nuestras pruebas puede estar escrita básicamente en cualquier idioma. Puedes ver que en Playwright, tiene Python, .NET, y más. Tenemos control total porque estamos accediendo a través de la API. Tenemos control total sobre la security, la entrada, los servicios de ubicación, incluso sobre el archivo de performance, y así sucesivamente. Las interacciones son reales porque, de nuevo, estamos llamando a estas APIs. Estamos pasando interacción de la misma manera que nuestro sistema operativo las está enviando. No estamos limitados a solo una ventana o una pestaña donde se están ejecutando nuestras pruebas. Podemos generar tantas ventanas y pestañas como queramos y ejecutar la prueba sobre ellas. Entonces, diciendo todo eso, ¿qué significa eso para nuestras pruebas de componentes ZenUI? Esto es lo que estamos haciendo en ubiq. Estamos utilizando una combinación de Playwright y storybook, como di algunas pistas en el camino, para probar nuestro

Entonces, ¿qué ganamos con este enfoque? En primer lugar, esta es una renderización real de componentes, no necesitamos simular nada, el navegador se encarga de eso. Ya escribimos historias para storybooks para mostrar nuestro componente así que las reutilizamos y ejecutamos la prueba sobre ellas. Esta es una prueba muy estable, no necesitamos simular, Playwright proporciona un muy buen feedback Playwright proporciona mucha estabilidad en nuestras pruebas, obtenemos una ejecución eficiente, puede ejecutarse en paralelo, puede ejecutarse en headless, lo que significa que puede ejecutarse en el CI, también puede dividirse en fragmentos o puedes ejecutarlo en varias máquinas en el CI, básicamente tienes mucho acceso a todo, al igual que cualquier programa de nodo que quieras ejecutar. Playwright, y quiero decir que esto podría ser toda una charla sobre cómo el debugging y tracing advanced pueden hacer eso. Y obtenemos la capacidad porque esto se está ejecutando en el navegador real, podemos hacer capturas de pantalla y podemos hacer pruebas de regresión visual. Podemos hacer eso en Storybook, podemos hacer eso en Playwright y así sucesivamente. Solo quiero mencionar algunas otras cosas que también están haciendo, Storybook también está avanzando sus capacidades de testing, Playwright tiene pruebas de componentes por lo que puedes usarlo no solo para pruebas de extremo a extremo y lo mismo ocurre con Cypress, proporcionan pruebas de componentes. Para hacer esto rápido, podemos ver aquí que cuando hablamos de pruebas de extremo a extremo y pruebas de componentes, tenemos un navegador real y la migración visual puede lograr ambas cosas, pero la principal diferencia es esta, que en las pruebas de extremo a extremo probablemente trabajaremos con un servidor de backend real y haremos solicitudes a un servidor real y a una database y probaremos flujos de usuario completos desde la ordenación hasta el pago, pero como son tan largos probablemente nos centraremos en el camino feliz mientras que en las pruebas de componentes bloquearemos nuestro backend, no queremos ir a nuestro backend para ejecutarlo y hay muchas herramientas para hacer eso y nos centraremos más en la variación y en el caso extremo. Muchas gracias.