¿Qué es un test automatizado y cómo evitar que un cambio rompa tu web?
Publicado el 2026-10-20 por frfrand
Pruebas automatizadas explicadas: tests unitarios, integración y end-to-end, ejemplos con Python, cobertura y errores comunes.
Un test automatizado es una comprobación que ejecuta un programa para verificar si una parte del software sigue comportándose como esperamos. Sirve para descubrir errores de manera repetible, especialmente cuando el proyecto cambia con frecuencia.
Imaginá que tenés una web para reservar turnos. Hoy una persona puede elegir fecha y horario. Mañana modificás el sistema de descuentos y, sin darte cuenta, los turnos empiezan a permitir reservas duplicadas. Un buen conjunto de pruebas puede detectar ese problema antes de publicar.
¿Por qué no alcanza con probar todo manualmente?
Probar a mano es útil, especialmente para descubrir problemas de experiencia de usuario. Pero repetir veinte acciones después de cada cambio es lento y fácil de olvidar.
Un test automatizado sigue instrucciones reproducibles. Puede ejecutarse cada vez que subís código y comunicar si la comprobación pasó o falló.
El objetivo no es eliminar las pruebas humanas; es liberar tiempo de tareas repetitivas y detectar regresiones antes.
Un ejemplo pequeño en Python
Imaginá una función que calcula el importe final de una compra. Podés escribir una prueba que compruebe el resultado esperado:
def calcular_total(precio, cantidad):
return precio * cantidad
def test_total_de_dos_productos():
assert calcular_total(12, 2) == 24Herramientas como pytest encuentran estas funciones y permiten ejecutar las comprobaciones. Si alguien introduce un error en el cálculo, la prueba debería fallar.
Por supuesto, una única prueba no valida toda una tienda. No cubre impuestos, descuentos, divisas, devoluciones ni errores de pago.
¿Qué tipos de tests existen?
Unitarios: comprueban unidades pequeñas de código, como una función de cálculo o una validación.
De integración: verifican que varias piezas trabajen juntas. Por ejemplo, que un backend pueda guardar y recuperar información de una base de datos de prueba.
End-to-end: recorren flujos cercanos a los que realiza una persona, como entrar a la web, registrarse y completar una reserva.
Cada tipo tiene costes y ventajas. Un test unitario suele ser rápido y preciso; uno end-to-end puede cubrir más componentes, pero también tarda más y puede fallar por motivos externos.
¿Qué es una regresión?
Una regresión ocurre cuando algo que antes funcionaba deja de hacerlo después de un cambio. Los tests son especialmente valiosos para prevenir este tipo de errores.
Si corrigís un fallo, una buena práctica es agregar una prueba que reproduzca el caso problemático. Así, si el mismo error vuelve a aparecer en el futuro, la automatización puede detectarlo.
¿Qué significa cobertura del código?
La cobertura intenta medir qué partes del código se ejecutan durante las pruebas. Puede ser útil para descubrir áreas completamente ignoradas.
Pero 100 % de cobertura no significa 100 % de seguridad ni ausencia de errores. Podés ejecutar todas las líneas de una función sin comprobar que los resultados son correctos ante datos inesperados.
Importa más la calidad de los escenarios: casos normales, límites, fallos previsibles y operaciones que involucran permisos o dinero.
¿Dónde se ejecutan las pruebas?
Pueden ejecutarse en tu computadora, en un entorno de CI como GitHub Actions o en un servidor de integración. Conviene aislar las bases de datos de prueba y no utilizar información real de clientes sin necesidad.
Una prueba que borra registros no debería ejecutarse accidentalmente contra la base de datos de producción. Revisá siempre las variables de entorno y credenciales utilizadas.
Errores habituales
Probar solo el caso perfecto. También hay que comprobar qué pasa si una API falla, llega un valor incorrecto o dos personas actúan al mismo tiempo.
Hacer pruebas frágiles. Si una prueba falla porque cambió un texto irrelevante, puede generar demasiado ruido y terminar siendo ignorada.
No mantenerlas. Cuando el producto cambia deliberadamente, los tests deben actualizarse para reflejar sus nuevos requisitos.
Creer que un check verde reemplaza revisar la producción. Los tests reducen riesgos, pero necesitás registros, alertas y la posibilidad de revertir cambios.
¿Cómo encaja en ArduMaker?
En proyectos desplegados sobre VPS administrados con ArduMaker, conviene ejecutar pruebas antes de cada despliegue importante. También podés utilizar entornos de staging para comprobar que backend, frontend y base de datos se comportan juntos antes de afectar usuarios reales.
En resumen: un test automatizado permite repetir verificaciones importantes. Cuanto mejor representa los riesgos reales del proyecto, más valor aporta.
Fuentes: Guía oficial de pytest · Buenas prácticas de pytest · GitHub Actions explicado.