La Magia Transformadora de Ordenar tus Advertencias de Prueba

Hola a todos, y gracias por unirse a la magia transformadora de ordenar sus advertencias de prueba. Hoy vamos a hablar sobre cómo prevenir las advertencias de prueba, con dos objetivos en mente. El primero es prevenir errores. Este es el más importante, y el segundo es mejorar la experiencia del desarrollador. Un poco sobre mí. Mi nombre es Victor Cordova. Trabajo en TravelPerk, una startup de Barcelona. Estamos construyendo la mejor plataforma de viajes de negocios del mundo. Si estás interesado, no dudes en unirte a nosotros.

Muy bien. Entonces, empecemos preguntando para qué sirven las advertencias de prueba. Las advertencias de prueba son mensajes creados por los desarrolladores de bibliotecas de terceros u otras tecnologías que nos dan pistas sobre qué evitar. Por ejemplo, definitivamente queremos evitar errores. Queremos evitar problemas deperformance. Queremos evitar preocupaciones desecurity, entre muchas otras. Esto es solo una muestra muy pequeña. También tenemos problemas deaccessibility, obsolescencias, y así sucesivamente.

Ahora, lo que sucede con las advertencias es que tienden a acumularse con el tiempo, y vale la pena preguntarse por qué. La primera razón es porque son bastante fáciles de ignorar. Entonces, básicamente, las advertencias de prueba son solo textos que se generan ya sea en tu máquina local o en otro servidor. Este texto, por sí solo, no hace nada. La segunda razón es porque no hacen que tu CI falle. Como desarrolladores, todos sabemos que prestamos mucha más atención a este color rojo que aparece cuando algo falla. Y finalmente, porque generalmente no son una prioridad. Vivimos en un mundo complejo. Tenemos tareas de producto, tareas técnicas, por lo que las advertencias pueden pasar fácilmente al final de esta lista. Ahora, es importante preguntarse por qué nos importa, sinceramente. Me lo pregunto a mí mismo. Entonces, ¿qué sucede si ignoramos las advertencias? Voy a darte un ejemplo muy pequeño de lo que puede suceder. Esta es una pequeña aplicación con un inventario de libros donde tenemos el título, la fecha de registro y la condición del libro. Así que imaginemos que voy a

para llenar esto ahora mismo. Voy a poner justo, bueno y terrible. Así que ahora voy a intentar usar esta funcionalidad de ordenamiento. Y veremos que todo excepto la condición está ordenado. Ahora, ¿por qué esto es preocupante? Porque esto podría ser fácilmente tu resultado en la ejecución de la prueba. Así que todo está en verde, lo cual no refleja realmente lo que está sucediendo. Entonces React, que es solo un ejemplo, te dará una advertencia que dice que cada elemento debe tener una clave única. Por eso debemos prestar atención a estas advertencias. Esto afecta la experiencia del desarrollador. Si estás tratando de hacer TDD, si estás tratando de depurar un problema, nadie quiere ver esto. Es bastante molesto. Es difícil encontrar cosas importantes. Entonces la experiencia del desarrollador se ve afectada. Ahora, podemos preguntarnos qué hacemos al respecto. Es un problema muy común en aplicaciones grandes, aplicaciones heredadas. Y a veces parece que realmente no podemos hacer nada. Pero somos ingenieros. Así que usemos algo de automatización. Así que creé esta pequeña biblioteca. Se llama jsreporter log validator. Y te permite agregar estas diferentes reglas a tus advertencias para que tu equipo no cree nuevas. La primera característica que tiene es que puedes agregar validaciones para ciertos patrones. Como verás, no es una cadena única para cada uno de los patrones. A veces tienen una parte dinámica. Puedes establecer un máximo. Entonces básicamente estás diciendo, okay, sabemos que tenemos este número de advertencias de este tipo. Pero no quiero más. La segunda es que puedes tener una medida de seguridad para advertencias inevitables. A veces instalamos bibliotecas de terceros que generan mensajes que no queremos. Pero a veces no podemos hacer nada al respecto. Así que simplemente podemos ignorarlo por ahora.

También tenemos la opción de fallar si se encuentra una advertencia desconocida. Entonces, tenemos este registro de advertencias permitidas. Si surge algo más, digamos, creas una solicitud de extracción actualizando la nueva versión de una biblioteca, entonces sabrás en tu compilación que debe fallar. Y si quieres que pase, entonces lo agregarás a esta configuración, pero al menos serás explícito. Y finalmente, digamos que realmente estás comenzando a solucionar tus advertencias. Dijiste, está bien, esta advertencia, no puedes cambiar el enrutador. No quiero que esté más. Y quiero solucionarlo. Entonces alguien lo soluciona. Pero quieres que esto desaparezca. No quieres permitirlo más. Entonces, esta última configuración te permite mantener esto actualizado. Este es un ejemplo de cómo se ve. Te dará un resumen de cuál es el comportamiento esperado, qué falló y qué puedes hacer al respecto. Solo un pequeño, un pequeño detalle. Esta biblioteca está en etapas iniciales. Así que siéntete libre de jugar con ella. Y también de dar algunos comentarios. Pero esto es solo un ejemplo de cómo puedes usar la automatización para solucionar este problema. Ahora, vivimos en un mundo donde los proyectos suelen tener grandes cantidades de advertencias, como mencioné antes. Entonces, ¿qué hacemos si ya tenemos muchas de ellas? Sugeriría hacer un análisis y distribución de trabajo muy simple. Hacer este análisis 80-20 probablemente te dará muy buenos resultados porque, en mi experiencia, las advertencias de prueba tienden a concentrarse en un subconjunto muy pequeño de archivos. Entonces, si identificas cuáles son las que realmente te están causando problemas, puedes priorizar y comenzar a resolverlas. Porque, nuevamente, tenemos que priorizar. Así que necesitamos priorizar según el riesgo y el esfuerzo. Si tienes una advertencia que realmente te está causando posibles errores, como la que mostré, pero tienes otras, que es una advertencia de obsolescencia de una biblioteca de la que te alejarás, digamos que te mudas de Moments a Ajs, entonces realmente no es importante en este momento. Y finalmente, por supuesto, necesitamos organizar y distribuir el trabajo. Esto es realmente importante entre diferentes equipos cuando estás lidiando con una aplicación grande, para que puedas resolverlo pieza por pieza. Así que solo un pequeño resumen. Te animaría en una línea básicamente a establecer una cultura anti-advertencias. También a aprovechar la automatización a tu favor. Y finalmente, abordar las advertencias existentes, porque valen la pena. Eso es todo por mi parte. Muchas gracias por escuchar.