Testing React Applications Like an Engineer

Imagina el siguiente escenario. Eres un ingeniero que trabaja en la NASA, y durante los últimos años has trabajado en el rover Perseverance de Marte. Y finalmente ha llegado el momento. Está en camino a Marte y todo va bien. Aterriza con éxito, pero luego hay un error inesperado. ¿Qué puedes hacer? No puedes simplemente volar a Marte y arreglarlo, bueno, porque es uno de los más caros Bueno, porque está a 140 millones de millas de distancia. Entonces, ¿qué haces? Exactamente para estos casos, cada función y cada línea de código en el rover tuvo que ser probada exhaustivamente. Y los ingenieros de la NASA son uno de los mejores testers del mundo. Replicaron los escenarios que pueden ocurrir en Marte en la Tierra. Crearon un pequeño campo de pruebas con un suelo similar al de Marte y expusieron el rover a temperaturas extremas, sonidos y vientos. Y podemos usar estas mismas técnicas cuando estamos probando nuestro software.

Y eso es lo que quiero ayudarte a hacer hoy. Quiero ayudarte a probar aplicaciones de React como un ingeniero. Mi nombre es Austin Shelby, y soy un ingeniero de software freelance de Finlandia. Algunos de ustedes pueden conocerme por mis videos de YouTube donde enseño programación. También soy el fundador de MandoFlow, la mejor manera de aprender mandarín chino en línea convirtiendo tus videos favoritos de YouTube en lecciones personalizadas de aprendizaje de idiomas. Así que cuando hablo de pruebas, quiero centrarme en cuatro problemas principales que la mayoría de los desarrolladores tienen, comenzando con que las pruebas se ven como una ocurrencia tardía.

Ahora, si has aprendido algo sobre pruebas, seguramente te has encontrado con una imagen que se ve algo así, la famosa pirámide de pruebas. Muestra la proporción óptima de pruebas de extremo a extremo, integración y unitarias que deberías tener en tu aplicación. O tal vez has visto una imagen como esta. O tal vez esta otra. Ahora, parece que todos tienen su propia opinión sobre la proporción perfecta. Pero creo que en la era de Next.js, no importa tanto porque la mayor parte del código que escribimos hoy en día se ve algo así. Ahora, los componentes de React en su forma más simple son solo una función de tu estado. Pero echemos un vistazo a esta única unidad, un solo componente de React. Aquí estamos obteniendo el usuario autenticado, que verifica la cookie de la solicitud y obtiene la sesión basada en ella. Si hay un usuario, lo redirigirá al perfil. Esta función de redirección lanza un error especial de Next.js. Y también estamos renderizando el formulario de registro. Así que esta única unidad está haciendo bastantes cosas.

Entonces, ¿deberíamos escribir una prueba unitaria para esto? No creo que importe. Y honestamente, me olvidaría del paradigma de integración unitaria y de extremo a extremo. Y más bien me centraría en el usuario porque la mayoría de las aplicaciones tienen uno de dos objetivos. O bien lograr que el usuario se registre o hacer que realice una compra.

Ahora, déjame mostrarte la aplicación de demostración que creé para esta charla. Podemos usar esto para explorar diferentes escenarios y cómo probarlos con Playwright. Así que en la aplicación de notas, puedo crear un nuevo usuario. Vamos a llamarlo Austin. Y añadir alguna contraseña. Una vez que nos registramos, nos redirige a la página de inicio y nos da un bonito mensaje de bienvenida. También podemos crear algunas notas. Como A, B y C. Y podemos ver que están siendo ordenadas por su tiempo de creación.

Ahora, usemos el registro como un ejemplo de cómo escribir una prueba simple con Playwright. Vamos a importar test y expect de Playwright, y luego vamos a escribir la prueba primero. Vamos a ir a la página de registro. Luego vamos a seleccionar el input de nombre de usuario por la etiqueta username y password. Luego vamos a llenar los datos. Test user y password 123. Y luego vamos a presionar enter. Luego vamos a realizar dos afirmaciones. Primero, que la página debería estar en la página de inicio y que tenemos el mensaje de bienvenida. Welcome test user. Pero falta una cosa más. Estas pruebas están tocando la base de datos y queremos que cada prueba comience desde cero.

Entonces, antes de cada prueba, queremos restablecer la base de datos. Y si ejecutamos esta prueba, obtenemos el siguiente informe. Todos los pasos pasan exitosamente. Pero a menudo escribir casos de prueba es más difícil que escribir la prueba. Y una gran manera de pensarlo es esta. Ahora mismo dice works, lo cual no es muy preciso. Creo que podemos hacerlo mucho mejor que eso. Un gran caso de prueba debería leerse como una historia de usuario bellamente escrita.

Pensemos en el caso de registro. Si escribimos una historia de usuario, sería algo así. Como nuevo visitante de la aplicación Notes, quiero registrarme para una cuenta usando un formulario de registro para poder comenzar a publicar notas. Esto es algo que una persona de producto escribiría, por ejemplo. Ahora, como ingenieros, estaríamos más cómodos con algo como el desarrollo guiado por comportamiento. En BDD, estamos usando un lenguaje compartido que tanto las personas técnicas como las de producto pueden entender. Y podemos comunicarnos sobre las diferentes funciones de nuestra aplicación.

Las pruebas son la mejor manera de documentar la funcionalidad de tu aplicación. Si la aplicación de alguna manera cambia, las pruebas fallan y podemos decir exactamente dónde algo salió mal. Pero muchas herramientas de BDD como Cucumber son un poco llamativas. Así que no recomiendo usarlas. Pero lo que podemos aprender de BDD es cuán específicos son cuando escriben los escenarios de prueba. Déjame darte un ejemplo. Para el registro, podemos escribir algo como esto. Dado que soy un usuario no autenticado, cuando navego a la página de registro, y entro test user en el campo de nombre de usuario, y entro password 123 en el campo de contraseña, y presiono enter, entonces debería registrarme exitosamente y debería ser redirigido a la página de inicio.

Ahora esto es muy preciso. Podemos escribir una prueba muy buena basada en esto. Pero es bastante largo. Resumámoslo en un solo párrafo. Registrar usuario con credenciales válidas y redirigir a la página de inicio. Volvamos a nuestra prueba y reescribámosla así.

A continuación, podemos usar una característica muy buena de Playwright, test step, para anotar nuestra prueba con diferentes pasos descriptivos. Así que para el primer paso, dado que soy un usuario no autenticado en la página de registro, y entro credenciales válidas y presiono enter, entonces debería registrarme exitosamente y ser redirigido a la página de inicio. Como dije antes, una prueba bien escrita debería leerse como una prosa bellamente escrita. Y se verá algo así en el informe de prueba. Y estos informes son una excelente manera de compartir la funcionalidad con las personas de producto.

Si quieren averiguar, por ejemplo, a qué página debería redirigir la aplicación después de un registro exitoso, pueden simplemente mirar los pasos de prueba y descubrir que debería redirigir a la página de inicio. Esta es la mejor manera de documentar la funcionalidad de tu aplicación. Así que piensa en la intención de tus historias de usuario. ¿Qué quiere lograr el usuario? Y comunica eso en un lenguaje que tanto las personas de producto como las técnicas puedan entender. Y anota tus pruebas usándolo para que sean más claras. Pero no solo queremos que nuestros casos de prueba sean claros, también queremos que nuestra prueba sea muy clara.

Y podemos hacer esto usando algo de estructura. Queremos que todas nuestras pruebas sean tan claras que podamos averiguar qué está sucediendo de un vistazo rápido. Y queremos usar una fórmula repetible que podamos usar una y otra vez para cada prueba que escribamos. Y el patrón que quiero enseñarte se llama arrange, act, assert. Así es como funciona. En el paso de arrange, hacemos cosas como restablecer la base de datos, sembrar algunos datos de prueba y configurar sesiones autenticadas. En el paso de act, hacemos cosas como navegar a la página objetivo, interactuar con diferentes elementos en la página, como campos de entrada y botones, y enviar formularios. En el paso de assert, seleccionamos diferentes elementos de la página, afirmamos el estado correcto e incluso verificamos que la URL sea correcta.

Ahora, usemos esta guía para escribir una prueba. Comencemos con la página de inicio. Aquí podemos ver tres nodos diferentes, y si podemos mirar las fechas, podemos ver que están ordenados en orden descendente. Así que escribamos la prueba que verifica esta funcionalidad. Vamos a comenzar dándole un nombre descriptivo, listar nodos en orden descendente por fecha de creación. Ahora, para el paso de arrange, queremos preparar el escenario, y hacemos esto sembrando algunos datos en la base de datos. Vamos a poner allí tres nodos diferentes, tercero, segundo y primero, que fueron creados en diferentes fechas. A continuación, pasamos al paso de act, y aquí simplemente vamos a la página de inicio. Eso es todo. Ahora, lo más crucial, el paso de assert. ¿Cómo podemos afirmar que los nodos están en el orden correcto?

Echemos un vistazo a la aplicación nuevamente. Tenemos los tres nodos, y necesitamos verificar que el contenido sea lo que esperamos. Pero, ¿cómo podemos seleccionarlos? En el formulario de registro, fue fácil porque podíamos simplemente seleccionar entradas por su etiqueta. Pero en la página de inicio, los nodos no tienen ninguna etiqueta. Entonces, ¿cómo los seleccionamos? Bueno, Playwright proporciona una gran solución usando algunos atributos HTML personalizados. Déjame mostrarte. Así que este es el componente de React para el nodo, y quiero que prestes atención al componente de enlace. Aquí, estamos renderizando el contenido, y este es el elemento que queremos seleccionar en nuestra prueba de Playwright, y podemos identificar este elemento usando un atributo HTML personalizado data test ID, y podemos darle cualquier nombre descriptivo que queramos. Aquí, le damos node content, y luego en nuestra prueba de Playwright, seleccionaremos todos los elementos por el ID de prueba node content, y luego haremos cuatro afirmaciones. Vamos a verificar que hay tres nodos y que los contenidos son tercero, segundo y primero. A continuación, podemos anotar cada paso, arrange, act y assert, para que sean más descriptivos. Primero, dado que hay tres nodos, cuando visito la página de inicio, entonces veo los nodos en orden descendente por fecha de creación.

Si ejecutamos la prueba, vemos un resultado de prueba hermoso. Y el último punto que quiero enfatizar, que probablemente sea el más controvertido, es que TDD a menudo se siente como una pérdida de tiempo, pero en realidad no estoy de acuerdo. Me encanta absolutamente el desarrollo guiado por pruebas. Déjame explicar por qué. Volvamos a la misión a Marte. Así que los ingenieros de la NASA fueron muy inteligentes. No solo crearon un rover, crearon dos, y son copias exactas entre sí. Uno de ellos lo enviaron a Marte, pero el otro lo mantuvieron en la Tierra, y eso por una muy buena razón. Imagina un escenario donde algo sale mal en Marte. Por ejemplo, el rover no puede subir una colina. Entonces, ¿cuál es el problema? Tal vez la colina es demasiado empinada, tal vez el suelo es demasiado arenoso y las llantas no pueden agarrarse, o tal vez la batería está agotada. Bueno, la forma en que pueden averiguar cuál es el problema real es reproduciendo el escenario en la Tierra y luego tratando de encontrar la solución. Y podemos usar esta misma estrategia exacta cuando estamos probando software. Déjame mostrarte. Imagina que en la aplicación de notas un día recibes un informe de error. Un usuario logró crear la misma nota dos veces, lo cual es muy extraño. Así que echas un vistazo en la base de datos, y miras la fecha de creación, y puedes ver que es casi la misma. Solo hay un segundo entre ellas, así que parece que el usuario logró enviar el formulario dos veces, lo cual no debería suceder. Así que esto podría ser un error. Así que usemos TDD para averiguar qué está pasando. Así que quiero que pienses como un ingeniero. Primero, queremos reproducir este error localmente, y luego queremos usar TDD para guiarnos hacia una solución. Podemos solucionarlo y desplegarlo con confianza ya que tenemos la prueba como salvaguarda. Así que comencemos. Así que pensemos en los tres pasos, arrange, act y assert. ¿Qué necesitamos tener para esta prueba? Primero, necesitamos tener una sesión autenticada. Segundo, necesitamos estar en la página de perfil. Luego necesitamos seleccionar la entrada por la etiqueta note, y luego necesitamos escribir algún texto y enviarlo dos veces. Luego necesitamos afirmar si se crearon una o dos notas. Muy bien, comencemos a trabajar en ello.

Entonces primero, lo llamaremos usuario autenticado puede crear una nueva nota. Así que el primer paso de organización, necesitamos crear una sesión autenticada. Durante el formulario de registro, simplemente ingresamos el nombre de usuario y la contraseña y enviamos el formulario, y de esta manera podemos crear una sesión autenticada. Pero eso es bastante lento y tenemos que manipular la interfaz de usuario. Somos programadores, así que somos muy perezosos, así que queremos automatizar esto. Entonces, ¿por qué no simplemente insertar manualmente el usuario y la sesión en la base de datos y luego adjuntar el token de sesión en la cookie? Y podemos hacer esto con Playwright muy fácilmente.

Déjame mostrarte. Así que para cada prueba, Playwright nos da contexto, que podemos usar para adjuntar cookies. Déjame mostrarte. Así que integra la función de usuario e inicio de sesión. Bueno, creamos el usuario y la sesión, y luego vamos a usar el contexto de Playwright para agregar una cookie con nuestro token de sesión. De esta manera, podemos crear un usuario y una sesión autenticada muy rápidamente. Ahora, pasemos a los siguientes pasos. Vamos a la página de perfil.

Obtenemos la entrada por la etiqueta note. Ingresamos Wow y presionamos enter. Luego hacemos dos afirmaciones. Afirmamos que hay una nota con el texto Wow. Lo ejecutamos, y todo funciona. Eso es increíble.

Ahora, pasemos al siguiente paso. Anotemos un poco mejor la prueba e intentemos reproducir el error. Añadamos algunos pasos. Dado que soy un usuario autenticado en la página de perfil y escribo una nueva nota Wow y presiono enter dos veces. Y aquí presionamos la tecla enter dos veces. Entonces debería ver una nueva nota con el contenido Wow. Ejecutamos la prueba, y falla. Deberíamos tener solo una nota, pero en realidad tenemos dos. Así que logramos encontrar el error. Ahora, vamos a solucionarlo.

Este es el formulario que usamos para crear nuevas notas. Y quiero que prestes atención al botón de envío. Mientras el formulario se está enviando, solo estamos cambiando el texto. No estamos realmente deshabilitando el botón. Así que vamos a solucionarlo deshabilitando el botón cuando el formulario se esté enviando. Ahora, cuando ejecutamos la prueba, todo funciona genial.

Así que aquí están los puntos principales que quiero que te lleves. Siempre que estés escribiendo pruebas, olvídate del paradigma de integración de extremo a extremo y de unidad. En su lugar, concéntrate en el usuario y en cuáles son los flujos de usuario más cruciales para tu negocio. A continuación, escribe casos de prueba claros usando un lenguaje que tanto el personal de producto como el técnico puedan entender. Este es el mejor lugar para documentar la funcionalidad de tu aplicación. En tercer lugar, estructura tu prueba con el formato de organizar, actuar, afirmar para que puedan ser fácilmente escritas y cualquiera pueda entenderlas. Y por último, usa TDD como una herramienta para resolver problemas complejos. Primero, reproduce el error localmente. Luego, corrígelo y despliega el cambio con confianza. Muchas gracias por escuchar. Me divertí mucho haciendo esto y espero que hayas aprendido algo nuevo. Si tienes alguna pregunta o simplemente quieres conectar, aquí están todos mis enlaces en redes sociales. Muy bien, por favor disfruta el resto de la conferencia y gracias de nuevo.