Testing en JavaScript en Platzi: por qué los tests no son opcionales en proyectos que crecen
Escribir tests se siente como trabajo extra — hasta que un cambio rompe algo en producción y no tenés forma de saberlo antes. El curso de Platzi lo explica bien.
OSCARLEON
OSCARLEON
Durante mucho tiempo fui del equipo de "testeo manual". Probaba en el navegador, si funcionaba, hacía deploy. Funcionó bien hasta que no funcionó — y el bug llegó a producción antes que yo me diera cuenta.
El curso de testing en JavaScript de Platzi cambió ese hábito.
Qué tipos de tests enseña el curso y cuándo usar cada uno
Tests unitarios para funciones puras — aquellas que dado un input siempre producen el mismo output. Son los más rápidos de escribir y los más valiosos por unidad de tiempo invertida.
Tests de integración para flujos que involucran múltiples módulos — un formulario que valida, llama una API y actualiza el estado. Más lentos de escribir, pero atrapan los bugs que los tests unitarios no ven porque viven en las interfaces entre módulos.
Tests end-to-end con herramientas como Playwright — simulan un usuario real navegando el sitio. Los más lentos y los más parecidos a la realidad. El curso cubre Jest y Testing Library en profundidad.
Cómo impacta en la calidad de lo que entregamos
En los proyectos de desarrollo web que construimos, los sistemas con tests de regresión son los que podemos modificar con confianza meses después del lanzamiento. El cliente que vuelve un año después con un cambio no tiene que preocuparse de que el cambio rompa algo que ya funcionaba.
Los proyectos del portafolio con mayor complejidad — sistemas de inventario, plataformas educativas, portales de cliente — tienen cobertura de tests críticos en los módulos de mayor riesgo.
¿Tu sistema puede crecer sin romper lo que ya funciona?
Un sistema sin tests es un sistema que da miedo modificar. Podemos revisar el estado actual y proponer una estrategia de testing acorde a la complejidad del proyecto.
La parte que el curso no puede darte
El criterio para saber qué testear. No todo merece test — escribir tests para cada línea de código es un desperdicio de tiempo. El criterio viene de la experiencia: testear los caminos críticos, las funciones con lógica compleja, los módulos que cambian con frecuencia.
Eso se aprende haciendo — y eventualmente fallando. El curso da la base técnica y el framework mental. La práctica da el criterio. Si querés hablar de calidad de código en tu proyecto, escribínos.
¿Te fue útil este artículo?
¡Gracias por tu feedback!