🧵 Los tests programados son una herramienta para obtener feedback.
Según el momento en que usemos los tests, nos darán un tipo de feedback diferente.
Lo vemos? 👇
Momento 1: Antes de escribir el código de aplicación.
El conocido Test First o TDD.
Nos dará un feedback sobre el diseño que tenemos en mente.
Es esta la forma en que quiero que se use mi código?
Momento 2: Después de escribir el código pero antes de probar de forma manual.
Nos dará feedback sobre si nuestro código se comporta como debería.
Estoy escribiendo el código de forma correcta?
Momento 3: Después de probar de forma manual.
Puede que nos dé feedback de algún caso de prueba que hemos obviado o no se podía probar manual, pero sobre todo creará una red de seguridad automática para el futuro.
Alguien ha modificado el código existente y ha roto algo?
Los momentos son, digamos, acumulativos.
Al feedback del momento 2 se suma el del momento 3. Y al del momento 1, se suman el del 2 y 3.
Resulta, que parece que Backend y Frontend tienen momentos preferidos diferentes a la hora de programar tests.
Backend se centraría sobre todo en el momento 2. Mientras que Frontend preferiría el 3 o directamente no hacer tests
x.com/jcesarperez/status/1848722851500855720
Yo no soy Frontend, pero me niego a pensar que los de Frontend programan peor o saben menos que los de Backend.
Entonces qué pasa?
DISCLAIMER: Sí, estoy generalizando, voy a hacerlo un poco más y no he hecho ningún estudio empírico serio
Para un backend, suele ser más fácil y rápido pobar su código programando un test que probar de forma manual.
Reiniciar la aplicación, levantar dependencias, poblar bases de datos, configuraciones, son tareas que llevan su tiempo como para hacerlas con cada prueba
También a la hora de comprobar el resultado del código. Incluso aunque uses postman o similar, es más sencillo escribir un assert que ponerte a explorar algunas respuestas json e ir a la base de datos o una cola de mensajería para comprobar que se ha comportado como debería
Pero para un frontend, es diferente. Sobre todo si ya tienen el backend montado.
Sí, es cierto que hay muchas funciones que se prueban muy fácil con tests unitarios.
Pero al final siempre necesitan comprobaciones visuales y su código despliega rápido
Como decía, los tests son una herramienta excelente para obtener feedback.
Son una herramienta muy efectiva. En algunos contextos más que en otros. Pero no son la única
Los tests vienen con costes. Los tests son código. Y como todo código hay que programarlo, hay que mantenerlo y hay que ejecutarlo.
Hay que diferenciar qué partes requieren invertir un coste mayor en tests y cuáles uno menor. O incluso ninguno!
Porque qué valor tiene un test que nunca se puso rojo?
Se creó, se ejecutó varias veces, siempre verde. Hasta que la funcionalidad cambió y el test dejó de existir como tal
Entonces habría que probar más de forma manual?
No he dicho eso. Dependerá mucho de tu contexto. Pero a lo mejor hay que gente que abusa de los tests.
Recordemos tb que los tests no garantizan que tu código no tiene errores. Los tests sólo prueban que hay errores cuando los hay
Hey, Julio! Pero entonces estás diciendo que en Frontend no hay que programar tests?
NO. En Frontend hay que usar tests. Pero la forma de programar tests, no tiene por qué ser la misma que en Backend. No suele serlo. Y está bien
En resumen:
Los tests son una herramienta de feedback.
Los tests hay que usarlos de forma efectiva para que aceleren nuestro desarrollo.
Dependiendo del contexto, la forma puede variar u otras herramientas pueden ser efectivas tb.
Frontend y Backend son contextos muy diferentes