¿Para qué usar pruebas?!

Hola a todos, soy Evitar, soy un Ingeniero de Frontend en Meta, y una de mis pasiones es trabajar en herramientas y bibliotecas de código abierto y frameworks para que otros desarrolladores los utilicen, y hoy vamos a hablar sobre uno de ellos. Ahora este en particular es una combinación entre esa pasión y mi otra pasión, que es Unitest. Me gusta tanto Unitest que en realidad construí un framework de pruebas unitarias. Quiero decir, no realmente un framework, ya tenemos suficientes de esos, pero construí un framework de validación de formularios que toma la sintaxis y el estilo de Unitest y bibliotecas como Mocha o Jest y los introduce en el mundo de la validación de formularios.

Pero antes de hablar sobre VEST en sí, intentemos primero comprender cuál es el problema con la validación de formularios. Quiero decir, hemos estado haciendo formularios durante 20 años, ¿cuál es el problema? Y creo que hay tres problemas principales en el mundo de la validación de formularios, y todo comienza con la estructura, o más bien, la falta de ella. Cuando escribimos nuestra característica y agregamos los formularios, realmente no sabemos dónde y cómo colocar la validación del formulario. Quiero decir, sí, tenemos un controlador de cambios y debería salir de allí. Pero dentro de los formularios, generalmente no solo nos preocupamos por los datos, nos preocupamos por la característica y la experiencia del usuario. Y luego, gran parte del código de validación se entrelaza con el código de la característica. Y luego obtenemos un montón de código espagueti, realmente, que se trata tanto de la validación del formulario como de la experiencia del usuario. Y luego, cuando volvemos a mantener la característica, como meses después, y tratamos de agregar cosas o eliminar cosas o hacer cambios, como hacer que los campos dependan entre sí, tenemos que desmontar todo el código específico de la característica que escribimos y volver a montarlo de una manera adecuada a nuestras necesidades actuales.

Y otro problema es que los formularios y la validación de formularios son realmente difíciles de probar. Desafortunadamente, los formularios son las partes de nuestras aplicaciones con mayor interacción. Es donde las personas tocan, desplazan, escriben, básicamente hacen clic. Y también es de donde proviene el dinero. Y debido a que esta es la parte de nuestra aplicación con mayor interacción, también es la más propensa a errores. Desafortunadamente, es realmente, realmente difícil de probar. Quiero decir, todo lo que deseas hacer en términos de prueba de validación de formularios debe pasar por todos los flujos. Ya sea simulación de eventos de usuario o debes pasar por todos los datos. Y es realmente difícil de probar, especialmente si tienes alguna lógica de validación compleja por la cual no deseas pasar completamente. Y terminamos sin probar esas cosas, y eso es una pena.

Pero, ¿qué tipos de validaciones de formularios existen? Quiero decir, esa no puede ser la primera biblioteca de validación de formularios. Quiero decir, todos hemos utilizado bibliotecas de validación de formularios, tanto en el cliente como en el servidor. Así que intentaré dar una breve descripción de lo que hay, y luego entenderemos cómo VEST es diferente.

Y primero tenemos los comparadores funcionales, como funciones básicas como isEmail, isNumber, más largo que, que básicamente nos dan una respuesta booleana si algún valor cumple con ciertos criterios. Y esto es realmente simple y también es muy útil. Pero no se preocupa mucho por la estructura, no nos ayuda con el mantenimiento, y tampoco con las pruebas. Y esto es muy útil, pero no es una solución completa para la validación de formularios.

En segundo lugar, tenemos las bibliotecas de validación de esquemas que dan un paso más allá de lo que acabamos de describir. Toman la forma de los datos, la estructura de los datos y la forma de los datos en su totalidad debe cumplir con ciertos criterios. Y esto es bueno principalmente para el nivel de la API. Pero cuando se trata del cliente, no tanto. Quiero decir, ¿qué haces cuando el usuario interactúa con un formulario, como escribir en el campo de nombre de usuario? ¿Validas todo el conjunto, todo el esquema? Y también es muy difícil describir ideas complejas, como campos que dependen entre sí, dentro de un esquema. Así que es muy útil, pero no necesariamente de la forma en que queremos que sea.

Y en tercer lugar, tenemos en el cliente bibliotecas de validación de estado de formulario o gestión de estado específicas del framework que son específicas del framework y te proporcionan componentes o controladores de eventos o directivas para usar en tu aplicación. Y lo que hace básicamente es quitarte un poco de control, pero te brinda toda la gestión de estado del formulario y toda la validación de formularios para el formulario, y luego estás listo y es bueno. Pero el problema es que es específico del framework, específico del framework de interfaz de usuario, por lo que no podemos compartir fácilmente entre el cliente y el servidor, o entre Angular o React o Vue, y la mayoría de nosotros tenemos al menos algunas aplicaciones o algunos tipos diferentes de nuestras aplicaciones. Y también, porque te quitan el control, ponen sus cosas dentro de tu aplicación, es muy difícil recuperar ese control cuando necesitas evitar algún comportamiento. Es bueno, pero no necesariamente, nuevamente, de la forma en que queremos que sea.

¿Y cómo encajan las pruebas unitarias? Esto es Test.js. Hace un par de años, como hace seis años, comencé a escribir pruebas unitarias como parte de mi trabajo, y me di cuenta de esto. Cuando escribimos una prueba unitaria, tenemos nuestra suite de pruebas unitarias. Que generalmente comienza con un describe, no tiene que ser así, pero comienza con alguna suite de nivel superior que describe la idea de lo que estamos probando nuestra función o aplicación o lo que sea. Dentro de ella, tenemos una serie de pruebas que básicamente describen qué afirmación estamos haciendo ahora y cuál es el error que mostraremos en caso de fallo. Luego tenemos nuestra afirmación, por ejemplo, expect y lo que esperamos que sea. ¿Y si pudiéramos usar esa misma idea dentro del mundo de la validación de formularios? Quiero decir, es prácticamente lo mismo. Cuando escribimos un formulario, tenemos nuestro concepto más alto de un formulario que queremos describir. Dentro de él, tenemos los diferentes campos, un conjunto de campos que queremos probar, y luego solo queremos hacer una afirmación. Ahora, en lugar de afirmar el comportamiento, queremos afirmar los datos. Jugué con esta idea específica, y esto es lo que se me ocurrió. Primero, creamos nuestra suite de validación de formularios.

Esto es ligeramente similar a una suite de pruebas unitarias. Describes, opcionalmente, el nombre del formulario que estás validando, y también pasas los datos del formulario con los que el usuario acaba de interactuar. Dentro de él, agregas, obviamente, una serie de pruebas. Tienes una prueba que es muy similar a una prueba de pruebas unitarias, solo que agrega un campo adicional que es el nombre del campo que estás validando, así que en este ejemplo, Nombre de usuario. Luego, pasas el mensaje que el usuario vería en caso de una validación fallida, tanto para descripción dentro del código, como para que el usuario lo vea. Luego, lo que tienes es básicamente una afirmación, y en lugar de usar Expect, que no es realmente bueno para producción, estoy usando Enforce que escribí, que es mucho más adecuado para la validación de formularios, tanto en términos de lo que hace como de cómo se comporta. Así que tienes Enforce, pasas cualquier dato que desees. En este caso, pasamos los datos del formulario, y luego agregamos nuestra afirmación, por ejemplo, NoEstáEnBlanco. Ahora, obviamente, la validación de formularios no es tan simple, y podemos agregar múltiples validaciones por campo. Podemos agregar tantas como queramos, e incluso podemos agregar más, incluso validaciones complejas, por ejemplo, validaciones asíncronas, en caso de que, por ejemplo, los nombres de usuario ya estén en uso en un servidor. Y al igual que en Jest y Mocha, pasar una función asíncrona hace que la prueba sea asíncrona. ¿Y qué pasa si, bueno, no queremos ir al servidor, en caso de que la validación ya esté fallando para el campo desde el principio, como cuando el nombre de usuario ya está fallando porque es demasiado corto? Bueno, podemos decirle que lo omita cuando tengamos errores para el campo de nombre de usuario. ¿Y qué pasa si aún no queremos que el usuario vuelva una y otra vez por el mismo nombre de usuario, incluso si es válido localmente? Entonces, bueno, podemos memorizarlo y decir, bueno, si el nombre de usuario vuelve a escribir el mismo nombre de usuario nuevamente, pues no vayas al servidor nuevamente. Y esto es solo la punta del iceberg en términos de lo que VEST puede hacer. Tiene muchas características, muchas capacidades y responde a todos los problemas que normalmente tenemos en la validación de formularios. Ahora, una de las características interesantes es que VEST funciona con cualquier cosa en JavaScript, básicamente. Si usas un framework o sin un framework o en un servidor o en cualquier lugar, realmente puedes usar VEST. Y una característica destacada de VEST es el soporte completo de TypeScript. Puedes validar cambios al interactuar. Puedes tener múltiples validaciones por campo individual. Tienes validación de advertencia. Por ejemplo, la fortaleza de la contraseña, que no solo falla el envío, sino que simplemente le dice al usuario: `Oye, aquí hay un problema`, y pone la validación en una categoría diferente. Podemos tener campos que dependen entre sí, como la confirmación y la contraseña. Tenemos validaciones asíncronas y tenemos memorización. Podemos agrupar pruebas, como en Nest para Describir. Podemos componer reglas de validación. Podemos extender VEST para agregar más aplicaciones personalizadas. Todo está estructurado y no depende de un framework. Puedes instalar VEST muy fácilmente, npm install vest. Trae algunas dependencias que son específicas de VEST, todas fueron escritas para VEST, por lo que no trae nada de terceros. Hay un sitio web de documentación, vestjs.dev. También hay un enlace al servidor de Discord allí, y si quieres echarle un vistazo, puedes probar todo esto. Muchas gracias. Y estoy muy emocionado de verte formar parte de la comunidad de VEST. Gracias.