El testing automatizado de aplicaciones web es el conjunto de pruebas que se ejecutan solas en cada cambio de código y bloquean el despliegue si algo se rompe. Combina muchas pruebas pequeñas de lógica y de API con unas pocas pruebas end-to-end en Playwright sobre los flujos que generan ingresos. Lo incluimos en cada proyecto de desarrollo de aplicaciones web a medida en Madrid.
Sin pruebas automáticas, cada despliegue depende de que alguien recorra la aplicación a mano. Ese repaso crece con cada funcionalidad y se recorta justo cuando hay prisa. El coste llega después: un error en el cálculo de precios que descubre un cliente, o un equipo que deja de mejorar el código porque tocarlo da miedo.
Al terminar sabrás qué probar en cada capa y qué exigir a quien mantiene tu aplicación, empezando por una auditoría técnica antes de heredar un código si el proyecto ya existe.
Qué es el testing automatizado de aplicaciones web
El testing automatizado de aplicaciones web es la práctica de escribir código que verifica el comportamiento de otro código y ejecutarlo en cada cambio. Abarca desde una función de cálculo aislada hasta un recorrido completo en un navegador real, y devuelve un resultado binario: el cambio se puede desplegar o queda bloqueado.
El testing de apps móviles en iOS y Android tiene su propia guía. Aquí el foco es la aplicación web y su API, donde el navegador y el servidor se prueban por separado.
La pirámide de pruebas aplicada a una web con API
La pirámide de pruebas ordena las pruebas por coste: muchas en la base y muy pocas en la cima. Mike Cohn la presentó en su libro Succeeding with Agile, y Ham Vocke la desarrolla en The Practical Test Pyramid, publicado en martinfowler.com en 2018 con una regla simple: cuanto más alto el nivel, menos pruebas.
- Unitarias: Qué prueban: una función o un módulo sin red ni base de datos. Herramientas habituales: Vitest o Jest en JavaScript, PHPUnit en PHP. Son las más rápidas porque no salen del proceso.
- Integración y API: Qué prueban: los endpoints contra una base de datos real. Testcontainers, una librería de código abierto, levanta una base de datos desechable en cada ejecución y evita simulaciones que no se parecen a producción.
- End-to-end: Qué prueban: un recorrido de usuario completo en el navegador. Son lentas y se vuelven frágiles si se abusa de ellas, por eso se reservan para los flujos críticos.
Pruebas end-to-end con Playwright: cuándo sí y cuándo no
Playwright es un framework de pruebas end-to-end que controla Chromium y Firefox, además de WebKit, con una sola API, según su documentación oficial de Playwright. Antes de cada clic comprueba que el elemento es visible y está habilitado, lo que elimina las esperas manuales que vuelven inestables las suites antiguas.
- Sí, en flujos de ingreso: el alta de cliente y el pago, o cualquier recorrido cuyo fallo cuesta ventas.
- Sí, para compatibilidad con Safari: WebKit es el motor de Safari y Playwright lo ejecuta en el mismo pipeline que el resto.
- No, para reglas de negocio: un descuento por tramos se prueba en unitarias, en una fracción del tiempo.
- No, para cada variante de formulario: las combinaciones de campos se cubren en la API y el navegador solo confirma que el envío funciona.
Cómo encaja el testing automatizado en el pipeline de CI
El testing automatizado solo protege si es obligatorio: ningún cambio entra en la rama principal con la suite en rojo. El punto de control natural es un flujo de pull request con revisión obligatoria, donde las unitarias y de API corren en cada push y Playwright corre antes de fusionar.
Después, el pipeline de CI/CD con Docker y despliegues sin corte publica la versión que ya ha pasado las pruebas. Cuando la suite crece, Playwright la reparte entre varias máquinas con la opción shard. Esa misma suite protege una migración a la nube de una aplicación de empresa si la ejecutas contra el entorno nuevo antes de mover el tráfico.
La pirámide cubre la corrección funcional. El comportamiento con miles de usuarios a la vez se mide con pruebas de carga y rendimiento antes de una campaña, y la conformidad formal del cliente con unas pruebas de aceptación con tu proveedor de software.
CodeZone Pro Tip: configura Playwright para que en CI reintente cada fallo con traza y pruebe escritorio y móvil sin tocar los tests.
// playwright.config.mjs
import { defineConfig, devices } from '@playwright/test';
const enCI = !!process.env.CI;
export default defineConfig({
testDir: './e2e',
// Un test.only olvidado no puede dejar sin ejecutar el resto de la suite en CI
forbidOnly: enCI,
// Dos reintentos en CI separan un fallo intermitente de un error real; en local, ninguno
retries: enCI ? 2 : 0,
// Reparto por test individual: los shards quedan equilibrados aunque haya ficheros grandes
fullyParallel: true,
// Tope de una hora para que el pipeline termine y el informe se genere igualmente
globalTimeout: 60 * 60 * 1000,
// El formato blob permite unir después los informes de cada shard con merge-reports
reporter: enCI ? [['blob'], ['github']] : 'html',
use: {
baseURL: process.env.BASE_URL ?? 'http://localhost:3000',
// La traza se guarda solo al reintentar: diagnóstico completo sin inflar los artefactos
trace: 'on-first-retry',
},
projects: [
{ name: 'chromium', use: { ...devices['Desktop Chrome'] } },
{ name: 'firefox', use: { ...devices['Desktop Firefox'] } },
{ name: 'webkit', use: { ...devices['Desktop Safari'] } },
{ name: 'movil', use: { ...devices['iPhone 13'] } },
],
webServer: {
command: 'npm run start',
url: 'http://localhost:3000',
// En CI siempre se arranca un servidor limpio; en local se reutiliza el que ya esté abierto
reuseExistingServer: !enCI,
},
});Con esta configuración, un fallo en el pago dentro de Safari bloquea la fusión del cambio y deja una traza paso a paso para reproducirlo. Tu equipo arregla el error antes del despliegue y deja de enterarse por una reclamación.
Lo Que Pagas Cuando Cada Despliegue Es una Apuesta
Una aplicación sin pruebas obliga a elegir entre desplegar con miedo o dejar de desplegar. Las dos opciones generan deuda técnica que se acumula sin pruebas y encarecen cada cambio posterior. Empezar por los dos o tres flujos que facturan ya cambia esa dinámica.
En Codezone montamos la suite de pruebas y el pipeline dentro del propio proyecto y los dejamos documentados en el repositorio. Cuéntanos qué parte de tu aplicación nadie se atreve a tocar y te proponemos por dónde empezar.
