Pruebas para una Mejor Experiencia de Desarrollador

♪♪ Hola, soy Will Klein, y quiero hablarles sobre las pruebas. En particular, quiero compartir cómo las pruebas pueden ayudarnos a tener una mejor experiencia como desarrolladores. Comencé una empresa llamada ToolSpace, una consultoría enfocada en construir excelentes herramientas para desarrolladores y mejorar la experiencia del desarrollador para todos porque es lo que más disfruto hacer.

Y trabajar con pruebas, buenas pruebas de hecho, es una de mis cosas favoritas para tener en mi arsenal, y me ayuda a disfrutar aún más escribir código de lo que ya lo hago. Me gustaría compartir con ustedes hoy cómo lo hago para que ustedes también puedan hacerlo. Permítanme comenzar compartiendo una historia rápida.

Tengo un proyecto de cliente donde recientemente envié mi primera característica, y fue un poco desafiante de implementar, en parte porque era nuevo en la base de código, pero también porque sentía que la experiencia del desarrollador estaba un poco carente. Algunos herramientas necesitaban ser configuradas, y las pruebas en particular, bueno, había pruebas unitarias para algunas cosas, pero no había pruebas de integración, y no había pruebas de extremo a extremo. Así que si hacía un cambio, realmente no tenía la confianza a la que estoy acostumbrado de saber que todo sigue funcionando. Así que trabajé un poco más despacio de lo habitual, y fui muy cuidadoso con entender el impacto de mis cambios.

Y pensando en retrospectiva, realmente debería haber insistido, realmente deberíamos tener algunas pruebas en su lugar. He estado allí donde simplemente he seguido adelante, y, ya sabes, sí, desearía haber tenido esas pruebas. Y de hecho, después de que envié esta característica hace unas semanas, la semana después el cliente se puso en contacto conmigo y dijo, oye, ese trabajo que hiciste en esta cosa, rompió algo. Eso es muy importante, y necesitamos que lo arregles. Y yo estaba como, oh, caray. Estaba trabajando en otra cosa, tuve que detener lo que estaba haciendo, tuve que cambiar de contexto a lo que había estado trabajando, y comencé a investigarlo. Y mientras lo investigaba, seguía pensando, hmm, realmente no creo que fuera mi cambio, pero no tenía pruebas. No tenía pruebas para saber eso, para darme esa confianza de saber que todo seguía funcionando después de que hice el cambio. Así que hice mi investigación, y después de un período de tiempo bastante corto, descubrí que no era yo. No fue mi cambio. Y honestamente, desearía que fuera yo, porque si lo fuera, sabría lo que cambié. Podría haberlo resuelto bastante rápido. Pero en cambio, tuve que decirle a mi equipo que no sabía qué lo rompió, no fui yo, lo que significaba que otros dos desarrolladores entonces tuvieron que detener lo que estaban haciendo y luego mirar qué salió mal. Así que una especie de caso clásico de no tener las pruebas que deberías tener, y tu experiencia como desarrollador se descompone completamente, tu productividad se va por la ventana, teniendo que cambiar de contexto, teniendo que detener lo que estás haciendo, teniendo que averiguar qué es esto en lugar de construir características y hacer cosas geniales. Este no es el lugar donde nadie quiere estar.

Es una cosa tener una prueba fallando, y tal vez tu prueba no tiene sentido, y no la entiendes, pero al menos sabes que algo está mal, ¿verdad? Es mucho peor cuando no tienes fallos en las pruebas, porque no tienes todas las pruebas correctas, y no entiendes qué está mal en absoluto. No sabemos cuándo se introdujo el problema en este caso, y en su lugar, hubiera sido genial si hubiéramos tenido algunas pruebas para detectarlo.

Así que esto me lleva a mi primera lección. Podríamos escribir la prueba ahora. Ahora que sabemos que hay un problema, podríamos escribir una prueba para esta funcionalidad que estaba rota, pero ¿cuándo deberíamos haber escrito esas pruebas? ¿Cuándo fue el momento ideal para haberlas escrito y luego tenerlas en el futuro? Hablemos de TDD. TDD es donde escribimos nuestras pruebas primero. Y esto puede ser genial, porque si escribimos nuestras pruebas primero, hay esta noción en TDD donde de alguna manera diseña la arquitectura de nuestra aplicación y cómo vamos a implementar las cosas. Y TDD es genial cuando sabemos dos cosas. Sabemos lo que necesitamos escribir, y sabemos dónde deben ir esas cosas que necesitamos escribir. Para saber esas dos cosas, ayuda tener patrones bien establecidos y frameworks que rara vez cambian, una forma establecida de hacer las cosas a la que estamos acostumbrados.

Eso no es front-end en 2024. Creo que tenemos el panorama más competitivo hasta ahora para frameworks y bibliotecas. Y eso es algo bueno. Eso es bastante genial, de hecho. He trabajado en algunos proyectos diferentes en el último año, y todos ellos han tenido tal vez como dos o tres frameworks diferentes y luego un puñado de bibliotecas diferentes. Las cosas se implementan de diferentes maneras, en diferentes proyectos, todo el tiempo. Si vas de una empresa a otra, podrías estar viendo dos arquitecturas muy diferentes.

Así que, sí, saber dónde poner todo desde el principio y usar pruebas para guiar eso, mira, esa es la cosa. Necesitas saber dónde van a ir las cosas para saber dónde vas a escribir tus pruebas. Y eso simplemente no es genial. TDD, front-end, no creo que se mezclen. Siempre he tenido problemas con eso. Así que hablemos de cuál es la alternativa. Probar al final tampoco es genial. ¿Quién ha escuchado a alguien decir esto? El trabajo de la característica está hecho. Solo necesito escribir las pruebas. He dicho esto en el stand-up. He escuchado a otros decir esto en el stand-up. Esto tampoco es genial. Esperar hasta el final solo convierte las pruebas en una tarea tediosa.

Y inevitablemente no vas a probar todas las cosas porque estás pensando en terminar el trabajo y no en cuáles son las cosas que necesitan pruebas. Así que tengo una alternativa para sugerir. Y esto es una especie de híbrido de los dos. Más o menos pseudo-TDD, me gusta escribir pruebas tan pronto como sé lo que estoy haciendo. Así que lo que haré es comenzar el desarrollo de la característica o comenzaré a arreglar un error. Y continuaré hasta que tenga una idea muy clara de qué cambios necesito hacer para que las cosas funcionen.

Y usualmente, una vez que he logrado que esa característica funcione de alguna manera, tal vez todavía haya un montón de requisitos por implementar, generalmente tengo una buena idea, oh, aquí están las cosas involucradas. Aquí están las partes del sistema que van a tener cambios que impactan esto. Y ahora puedo tener una idea de, oh, aquí están algunas de las pruebas que necesito escribir. Y así escribiré tantas pruebas como pueda en este punto. Y esto es valioso por una razón realmente importante. Esta parte donde, este momento en el que he descubierto lo que estoy haciendo con mi característica o dónde está el error, este es el momento crítico en mi flujo de trabajo de desarrollo donde he resuelto las cosas, pero todavía tengo un montón de trabajo por hacer. ¿Y no sería genial si tuviera mis pruebas para ayudar a guiar mi trabajo de aquí en adelante? Así que mientras implemento mi código, no tengo que ir a probarlo manualmente. Estoy viendo mis pruebas pasar de rojo a verde. Estoy viendo mis pruebas pasar en tiempo real mientras escribo código.

Esto es increíble. O tal vez veo que algunas pruebas fallan y tengo esas pruebas escritas. Definitivamente he tenido características donde implemento algo. Esta cosa en la que me concentré está funcionando. Paso a la siguiente cosa. Implemento algunos requisitos más. Y vuelvo a esa vieja cosa en la que trabajé hace unos días y ya no funciona. ¿Qué lo rompió? No lo sé. Así que realmente me gusta usar las pruebas como un ciclo de retroalimentación para mantenerme en el camino, para decirme cuándo estoy haciendo las cosas bien, cuándo estoy haciendo las cosas mal. Y definitivamente en el caso de UI, donde potencialmente estamos llenando un montón de campos, haciendo clic en algunos botones y probando todo un flujo de trabajo de usuario, hacer eso manualmente una y otra y otra vez se vuelve tedioso después de solo dos o tres veces. Y a menudo estoy haciendo cientos de cambios, a veces probándolos docenas de veces. Es genial cuando tengo mis pruebas, ejecutando esas pruebas automatizadas por mí y diciéndome que todo está bien. Y por supuesto al final, revisaré mi UI, pero lo haré una vez al final y todo estará más o menos, siempre estará funcionando si mis pruebas estaban detectando cosas.

Muy bien. El siguiente desafío que me gusta discutir es qué probar. Y hay una estrategia que veo un poco abusada para esto. Y esa estrategia se llama cobertura de código. La prueba más inútil que he escrito, que he ido y dicho, esta prueba realmente no tiene sentido. ¿Por qué la escribí? Veré un mensaje de commit que dice, esto es para aumentar la cobertura de código. Aprendí en ese momento que tal vez escribir pruebas para la cobertura de código no es la mejor estrategia. Así que la cobertura de código en la superficie no es tan mala. La cobertura de código es una métrica para medir cuánto de tu código es ejecutado por tus pruebas. Saber que todos los caminos a tu código son probados por algo, eso es genial, ¿verdad?

Eso es útil como tal. Pero en las pruebas, a menudo incentiva lo incorrecto, que es escribir una prueba, pero no necesariamente una buena prueba. Y creo que nos distrae de donde realmente deberíamos estar enfocándonos. ¿Recuerdas a nuestros usuarios? Esto realmente se trata de ellos. Bueno, quiero que no solo se trate de ellos, quiero que se trate más de nosotros.

Así que pensemos en ellos nuevamente por un minuto. Para construir UI, generalmente es algo para ayudar a alguien a completar una tarea. Usan esta aplicación como una herramienta. Les ayuda a hacer su trabajo para que puedan recibir su pago. Nuestra herramienta debe asegurarse de que siempre haga eso, y que nunca falle. Y si vamos a probar algo, queremos centrarnos en cuál será ese impacto para el usuario. Si esto no funciona, ¿les importa?

Así que en lugar de la cobertura de código, podemos probarlo en términos de cobertura de experiencia del usuario. Prioriza lo que más importa a nuestros usuarios y pruébalo realmente bien. ¿Cuál es ese flujo de trabajo que nuestro producto promete que ayuda a alguien a realizar? Debemos asegurarnos de que ese flujo de trabajo siempre funcione sin importar qué. Pero luego tal vez haya otras cosas. Como digamos, subir un avatar y poder recortarlo como puedes en Slack y cambiar su tamaño o ajustarlo. Eso es agradable de tener. Y espero que eso continúe funcionando. Pero al final del día, eso es agradable de tener. Y si probar eso, lo cual realmente no es tan fácil, si eso va a ser costoso, bueno, tenemos que justificar ese gasto. Y si no es de alto impacto para el usuario y el valor de nuestro producto, bueno, tal vez eso no debería recibir demasiada atención. Y claro, pruébalo como puedas. Pero en algún momento, diría enfoca tu esfuerzo de prueba en cosas que realmente importan y que son realmente impactantes para el usuario.

Okay. Así que hablamos sobre en qué enfocarnos al escribir nuestras pruebas y probar las cosas correctas. También discutimos anteriormente cuándo escribir nuestras pruebas y cómo deberíamos usarlas para crear un ciclo de retroalimentación útil. Hablemos un poco más sobre ese ciclo de retroalimentación.

Aquí hay un par de formas más en las que podemos aumentar nuestra experiencia como desarrolladores con las pruebas. Me gusta usar mis pruebas como documentación. Ahora, pensando en nuestro código, espero que mi código se documente por sí mismo. Espero que las cosas estén bien nombradas. Y al leer el código, puedo más o menos entender lo que está haciendo. Me está contando una historia de lo que está sucediendo aquí. Y no solo estoy mirando cosas que no tienen sentido.

Bueno, pienso en mis pruebas de la misma manera, pero un poco diferente. Así que déjame ver este primer ejemplo. La prueba dice que el código devuelve una cadena que es la suma de todos los valores de la fila. Este es el error más común que cometo al escribir mis pruebas porque acabo de escribir el código, y luego digo que la prueba debería hacer lo que hace el código en términos del código. Y esta es una gran oportunidad perdida para realmente contar la historia de para qué es el código.

Mirando el segundo ejemplo, muestra el total del carrito de compras. Esta descripción es muy diferente, pero al final del día es sobre lo mismo. Pero me lo está diciendo en términos del usuario. Si esto falla, sé qué no va a funcionar en la UI. Sé cómo va a impactar al usuario. Esta es la forma en que me gusta usar mis pruebas. Y pienso en esta idea de tomar todas mis descripciones de prueba y hacer que reporten esencialmente un documento que describa todas las cosas que mi producto hace por el usuario. Eso es lo que quiero que haga. No quiero que sea una especificación técnica. Quiero que sea una especificación de usuario.

Las utilidades de prueba y la documentación para Testing Library son tan buenas, tengo que mencionarlas. Testing Library fue originalmente escrita por Kensey Dodds, y tiene diferentes tipos de sub-bibliotecas y paquetes específicos para todos estos otros diferentes frameworks y bibliotecas. Es muy ubicua, y quiero decir que hace algo que muchas otras bibliotecas hacen muy bien, que es que incorpora las mejores prácticas. Y trata de guiarte en la dirección correcta de probar las cosas adecuadamente.

Una de las formas en que hace esto es que tiene un principio guía. Y lo leeré aquí. Cuanto más se parezcan tus pruebas a la forma en que se utiliza tu software, más confianza te pueden dar. La idea aquí es probar las cosas lo más cerca posible de la forma en que tus usuarios interactuarían con la aplicación. Esto es valioso por dos razones muy significativas.

Veamos un ejemplo donde no hacemos esto del todo. Aquí tenemos una salida HTML donde puedes ver que hay un atributo data-testid aquí. Y esto es para que nuestras pruebas puedan buscar cosas por este identificador y luego hacer una afirmación sobre ello. Esto es bastante común, y en el pasado he recomendado esto. Y hay casos donde si no puedes encontrarlo en un... si no puedes encontrar algo de manera consistente, usar un testid puede ser un buen recurso, pero nunca debería ser la opción predeterminada o lo primero a lo que recurras. Y aquí está el porqué.

Así que busquemos esto por el testid. Pero ¿y si tiene algún estilo aplicado que lo hace no visible para el usuario? Aún así lo buscará, y para proteger que realmente sea visible para el usuario de manera útil, necesitamos tener una afirmación muy específica para validar eso. Y hay una manera mejor. Aquí es donde usar algo llamado selectores accesibles es realmente útil. Hay un selector accesible llamado getbytext. Y aquí en este ejemplo, he eliminado ese data testid, y ahora estoy usando getbytext para buscar un valor de texto que está en la pantalla y visible para el usuario. Esto es mucho mejor. Va a proteger contra ese error donde no es realmente visible para el usuario, y va a tener este tipo de afirmación incorporada de que es visible de manera útil. Así que esto es genial. Nuestras pruebas serán más valiosas para nosotros.

Detectarán más problemas de los que de otro modo tendríamos. Y también van a mirar las cosas desde la perspectiva del usuario. El usuario no busca un testid. Ni siquiera puede verlo. Van a buscar texto en la pantalla. Entonces, ¿por qué no hacer lo mismo con nuestras pruebas, con nuestras utilidades de prueba? Y hay otras utilidades de prueba y selectores accesibles como getbyrole. Esto es realmente importante si estamos trabajando con navegación y tratando de encontrar cosas que tienen un cierto propósito en el documento, en el DOM. Y esa es la forma en que, si buscamos cosas por rol correctamente, es la misma forma en que los lectores de pantalla van a buscar cosas. Así que usar selectores accesibles es una herramienta importante para incorporar a tu conjunto de habilidades.

Muy bien. Este es uno de mis favoritos. Linters. Los linters, como ESLint, pueden ayudarnos a probar nuestras convenciones. Sin embargo, no se trata solo de convenciones de código. Hay reglas y plugins que pueden prevenir clases enteras de errores y proteger la experiencia del usuario. Lo más importante es que los linters nos dan retroalimentación en tiempo real sin tener que escribir pruebas individuales para cada una de estas cosas diferentes. A medida que implementamos algo que no se adhiere a las mejores prácticas, como digamos que agregamos una etiqueta de imagen a nuestro JSX, pero no agregamos ningún texto alternativo. No hay ningún atributo o prop alt, y no está allí. Podemos estar usando un plugin de linter que nos informa sobre esto de inmediato, asegurándonos de que lo agreguemos. Esta forma de prueba es increíble porque es casi automática.

En lugar de tener que escribir afirmaciones individuales como, en esta vista, esta imagen tiene texto alternativo, podemos simplemente configurar esta regla o plugin una vez, y luego va a detectar todo a partir de ahí a lo largo de esa dimensión de problemas. Muy bien. Aquí hay otro, custom matchers. Recuerdo cuando escribí mi primer custom matcher y vi mejorar la salida de mi prueba. Solo pensé, wow, esto es tan genial y tan fácil. Tengo un ejemplo muy simple que traje de VTest solo para mostrarte lo simple que es un custom matcher. Por supuesto, cuando usas un custom matcher, en realidad lo estás usando porque hay un escenario algo no simple, y quieres una mejor salida de la que te está dando. Solo un ejemplo rápido de caso de uso.

Digamos que tienes un carrito de compras, y tienes un montón de cosas en ese carrito de compras, y quieres asegurarte de que un descuento, un código de cupón se aplique a todo por igual, y estás viendo los descuentos aplicados. Tendrías que recorrer todo en el carrito de compras y asegurarte de que el descuento se aplique correctamente. Si realmente tienes afirmaciones verificando estos valores y escribes el código de prueba, hecho esto, la salida es útil al saber que la prueba falló, pero exactamente qué está roto no está muy claro.

Hay dos cosas en un custom matcher que ayudan en esto. Particularmente el mensaje, pero la primera cosa que ayuda es que podemos definir la condición de aprobación y decir esto es lo que necesita ser verdadero para que esta expectativa sea buena. Por supuesto, si esto falla, entonces el mensaje se mostrará. Aquí es donde tienes control total para proporcionar resultados útiles al próximo desarrollador que mire esto, que probablemente seamos nosotros, y poder especificar realmente eso, no sé, tal vez el último artículo o tal vez solo el primer artículo tenía el descuento aplicado. Poder proporcionar resultados muy útiles es realmente poderoso, y ahí es donde los custom matchers realmente entran en juego.

He hablado de un montón de cosas diferentes, pero realmente solo estoy rascando la superficie de todas las diferentes formas en que las pruebas pueden mejorar nuestra vida como desarrolladores. Quiero decir, si alguna vez escribes pruebas o trabajas con pruebas y sientes que es una tarea o no te está proporcionando valor, eso es una señal, eso es como un olor a código de que algo aquí debería cambiar. Tal vez necesites diferentes pruebas. Tal vez deberías estar usando diferentes utilidades. Tal vez estas pruebas deberían ser eliminadas y deberías escribir nuevas. Tal vez no deberías tener pruebas para esto. Tal vez debería ser probado a un nivel diferente.