Pruebas de navegador en Laravel 13: Pest con Playwright vs Dusk
La documentación oficial de Laravel 13 recomienda Pest 4 para pruebas de navegador: conduce Playwright, espera automáticamente y corre en paralelo, con suites E2E que pasaron de 12 minutos a 90 segundos en CI. Esta guía te muestra cómo instalarlo y escribir tu primer test.
Por qué Laravel 13 ya no te empuja a Dusk
El cambio de recomendación oficial: Pest 4 y su browser testing
Pest 4 se presentó como la release más grande del proyecto, con pruebas de navegador potentes, soporte de paralelismo e integración total con Laravel. La propia documentación de Laravel 13.x reconoce que el browser testing de Pest 4 ofrece mejoras significativas de rendimiento y usabilidad comparado con Laravel Dusk. En la práctica, eso significa que para un proyecto nuevo, la opción por defecto ya no es instalar Dusk sino montar Pest Browser Testing.
Qué significa para proyectos nuevos y para los que ya usan Dusk
Si empiezas un proyecto hoy, la ruta recomendada es Pest con Playwright. Si ya tienes una suite grande de Dusk, no tienes que migrar de golpe: Dusk sigue funcionando y mantenido, y la migración se puede hacer test a test. Lo importante es no asumir que lo que era la recomendación oficial en Laravel 10 o 11 lo sigue siendo en Laravel 13.
Dusk vs Pest Browser Testing: diferencias clave
ChromeDriver vs Playwright: qué navegador conduce cada uno
Dusk usa un ChromeDriver standalone: sin JDK ni Selenium, pero siempre Chrome y con la fragilidad de la versión del driver. Pest 4 no usa Selenium ni WebDriver: conduce Playwright, que gestiona su propio navegador dentro del mismo proceso de test. Eso elimina una clase entera de problemas de sincronización entre la versión del driver y la del navegador.
Esperas automáticas y estabilidad de los tests
La diferencia que más se nota al escribir tests es la espera. Con Dusk hay que acostumbrarse a las esperas implícitas y a veces explícitas cuando la página aún está cargando. Pest Browser Testing espera automáticamente a que la página termine de cargar antes de seguir, lo que hace los tests más estables y menos propensos a fallos intermitentes de timing.
Paralelismo: --parallel y --shard en CI
Pest 4 trae soporte de paralelismo de serie. Con --parallel reparte los tests entre varios procesos, y con --shard puedes dividir la suite en fragmentos que corren en distintos runners de CI. Dusk también permite paralelismo, pero la combinación de auto-waits, Playwright y sharding es lo que produce los recortes de tiempo más dramáticos.
Instalar Pest Browser Testing en Laravel 13
La instalación se hace en tres pasos: añadir el plugin de Pest, instalar Playwright y descargar los navegadores.
composer require pestphp/pest-plugin-browser --dev
npm install playwright@latest
npx playwright installcomposer require pestphp/pest-plugin-browser y npm install playwright
El plugin de Pest se instala como dependencia de desarrollo con Composer. Playwright se instala desde Node, por lo que necesitas Node disponible en el entorno. Ambos comandos son rápidos y no tocan tu configuración de producción.
npx playwright install: los navegadores
El último paso descarga los binarios del navegador que Playwright va a controlar. Se ejecuta una sola vez en desarrollo y también forma parte del setup del runner en CI, porque sin esos binarios los tests no pueden arrancar.
Tu primer test de navegador con Pest
Un test de login típico se escribe con una API expresiva: visitar una URL, rellenar el formulario, hacer clic y comprobar que el contenido esperado aparece.
it('lets a user sign in', function () {
$user = User::factory()->create();
$this->browse(function (Browser $browser) use ($user) {
$browser->visit('/login')
->fill('email', $user->email)
->fill('password', 'password')
->click('button[type="submit"]')
->assertSee('Welcome back');
});
});visit, fill, click y assertSee: el flujo de login
visit navega a la URL, fill rellena los campos, click pulsa el botón y assertSee comprueba que el texto aparece en la página. La parte interesante es que no necesitas esperas manuales: Pest espera a que la página cargue antes de cada interacción, así que el test se lee como una descripción de lo que hace el usuario.
Aprovechar las utilidades de Laravel dentro del test
Dentro del mismo test puedes usar todo el stack de testing de Laravel: factories para crear datos, event faking para simular eventos, y assertions de autenticación mientras navegas en un navegador real. Eso te da lo mejor de ambos mundos: datos reales de tu aplicación y una sesión de navegador de verdad.
Migrar de Dusk a Pest sin romper la suite
Mapeo de métodos: visit, type, press, assertSee
Si vienes de Dusk, la migración es casi mecánica porque la API es muy parecida. visit se queda igual, type de Dusk pasa a fill en Pest, y press pasa a click.
// Dusk
$browser->visit('/login')
->type('@email', 'test@example.com')
->press('Login')
->assertSee('Welcome');
// Pest
$browser->visit('/login')
->fill('email', 'test@example.com')
->click('button[type="submit"]')
->assertSee('Welcome');Migración incremental test a test
No hace falta migrar toda la suite en un día. Con el mapeo anterior, puedes ir convirtiendo tests de Dusk a Pest de uno en uno, verificando que cada test migrado sigue pasando antes de pasar al siguiente. Esa es la vía segura para equipos con cientos de tests E2E.
Ejecutar los tests E2E en CI
--parallel y --shard para recortar el tiempo
En CI, los tests de navegador se lanzan igual que cualquier test de Pest, pero con paralelismo para aprovechar varios cores o varios runners.
./vendor/bin/pest --parallel
./vendor/bin/pest --parallel --shard=1/4
./vendor/bin/pest --parallel --shard=2/4El caso documentado: de 12 minutos a 90 segundos
Un caso documentado de mayo de 2026 muestra una suite E2E que pasaba de unos 12 minutos con Dusk a unos 90 segundos con Pest 4 Browser Testing, combinando auto-waits, --parallel y --shard. Los resultados varían según la máquina y la suite, pero el orden de magnitud no es raro: menos esperas manuales y más procesos en paralelo cambian el tiempo total de forma drástica.
Cuándo seguir usando Dusk
Dusk sigue siendo una opción válida y mantenida, sobre todo si tu suite ya está escrita con él y funciona bien. Migrar por migrar no aporta nada si los tests son estables y el equipo no necesita el extra de paralelismo. La recomendación de Pest es para proyectos nuevos y para equipos que quieran recortar tiempo de CI; si estás cómodo con Dusk, no hay urgencia en cambiarte.
Conclusión
Laravel 13 apostó por Pest 4 para pruebas de navegador, y la combinación de Playwright, esperas automáticas y paralelismo de serie hace que los tests E2E sean más estables y mucho más rápidos en CI. Dusk no desaparece, pero para proyectos nuevos la respuesta oficial es clara. Prueba Pest Browser Testing con un test de login y decide con datos en la mano. Sigue leyendo el blog para más guías de Laravel y testing.