Laravel + WooCommerce + Pest: el starter que necesitás

Un desarrollador que mantiene WooCommerce en Laravel armó un starter completo con FrankenPHP como runtime PHP moderno y Pest para browser testing, publicando el setup en 2026 como punto de partida para quienes quieren mantener tiendas WooCommerce con tooling de Laravel sin depender exclusivamente del stack nativo de WordPress.

¿Por qué mantener WooCommerce con Laravel?

Ponele que tenés una tienda WooCommerce con 500 productos, integraciones con tres sistemas de facturación, lógica de descuentos personalizada y un equipo que conoce Laravel mucho mejor que WordPress. Cada vez que algo falla, estás metiendo mano en PHP procedimental, hooks de WooCommerce y un archivo functions.php que ya pesa más de lo que debería. La pregunta obvia es: ¿por qué no usar las herramientas que ya conocés?

Mantener WooCommerce con Laravel es una práctica que fue ganando terreno en equipos que no quieren reescribir todo desde cero pero sí quieren separar la lógica de negocio del core de WordPress. La idea no es reemplazar WooCommerce, sino usarlo como motor de e-commerce a través de su API REST mientras el código que importa vive en un proyecto Laravel con testing real, estructura clara y un flujo de deploy que no depende de FTP.

La diferencia respecto a los plugins nativos es concreta: en WordPress, toda la lógica va en hooks que se ejecutan en orden impredecible, con variables globales y sin ningún tipo de inyección de dependencias seria. En Laravel tenés contenedor IoC, Eloquent, jobs, queues y una suite de testing que no es un parche. Para equipos que ya trabajan con Laravel, la curva de mantenimiento se invierte: es más fácil mantener código Laravel que rastrear bugs en plugins enredados.

FrankenPHP: el runtime moderno para PHP

FrankenPHP es un servidor de aplicaciones PHP escrito en Go que actúa como SAPI (Server Application Programming Interface), reemplazando PHP-FPM en el stack. Según la documentación oficial de FrankenPHP, el runtime incluye soporte nativo para HTTP/2, HTTP/3, compresión Brotli y un modo «worker» que mantiene tu app Laravel en memoria entre requests, lo que elimina el overhead de bootstrap en cada petición.

Para desarrollo local con Laravel, esto es relevante. En vez de levantar Nginx + PHP-FPM + configurar vhosts, levantás FrankenPHP con un solo comando. El modo worker es especialmente útil: la app Laravel arranca una vez y queda en memoria, y cada request entra sin reiniciar el framework. En benchmarks del propio proyecto, el modo worker muestra mejoras de hasta 3x en throughput frente a PHP-FPM en aplicaciones Laravel.

Eso sí: el benchmark es del propio fabricante, así que tomalo con pinzas hasta que lo midas en tu setup específico. En producción la diferencia real depende mucho de tu hardware y de cuántos workers corrés en paralelo.

Pest: testing moderno en PHP

Pest es un framework de testing para PHP con sintaxis inspirada en Jest y Vitest. Si venís del mundo JavaScript, la sintaxis te va a resultar familiar inmediatamente. Si venís de PHPUnit, vas a notar que Pest corre sobre PHPUnit internamente, así que no estás tirando nada de lo que ya tenés.

Un test básico en Pest para verificar que la conexión con la API de WooCommerce funciona:

it('can fetch products from WooCommerce', function () {
 $client = app(WooCommerceClient::class);
 $products = $client->products()->all();

 expect($products)->toBeArray()->not->toBeEmpty();
});

La sintaxis es mucho más limpia que PHPUnit. No hay clases, no hay setUp y tearDown explícitos en cada test, no hay $this->assertEquals por todos lados. Instalación según la documentación de Pest: composer require pestphp/pest --dev y php artisan pest:install. Listo.

Browser testing con Pest y Laravel

Acá viene lo bueno: los tests de navegador. El setup del starter usa Pest con el plugin de browser testing para automatizar flujos reales de WooCommerce: agregar un producto al carrito, completar el checkout, verificar la confirmación de orden y chequear que el stock se actualizó.

Un test de carrito en un setup real se vería así:

use function Pest\Browser\browse;

it('can add product to cart and checkout', function () {
 browse(function (Browser $browser) {
 $browser->visit('/tienda/producto-test')
 ->press('Agregar al carrito')
 ->visit('/carrito')
 ->assertSee('producto-test')
 ->press('Proceder al pago')
 ->type('billing_email', '[email protected]')
 ->press('Realizar pedido')
 ->assertSee('Pedido recibido');
 });
});

¿Y qué pasó cuando este tipo lo probó en producción con el tema de WooCommerce real de su cliente? Exacto, falló tres tests porque el selector de «Agregar al carrito» cambiaba según el tipo de producto. Ese es el valor real del browser testing: te dice exactamente qué rompe cuando actualizás WooCommerce o el tema, antes de que se lo cuenten tus clientes. Lo explicamos a fondo en internacionalizar tu tienda WooCommerce.

Para equipos que mantienen tiendas con tráfico real, automatizar estos flujos antes de cada deploy es la diferencia entre un deploy tranquilo y una hora de soporte a las 11 de la noche (spoiler: todos hemos pasado por esa hora de soporte).

Estructura del starter Laravel para WooCommerce

El starter parte de una instalación Laravel estándar con algunas adiciones específicas. La estructura de directorios recomendada según la documentación de Laravel:

app/
 Services/
 WooCommerce/
 ProductService.php
 OrderService.php
 CustomerService.php
 Http/
 Controllers/
 WebhookController.php
config/
 woocommerce.php
tests/
 Feature/
 WooCommerce/
 ProductTest.php
 OrderTest.php
 Browser/
 CheckoutTest.php
 CartTest.php

Las variables de entorno clave en el .env:

WOOCOMMERCE_URL=https://tu-tienda.com
WOOCOMMERCE_CONSUMER_KEY=ck_xxxxxxxxxxxx
WOOCOMMERCE_CONSUMER_SECRET=cs_xxxxxxxxxxxx
WOOCOMMERCE_VERSION=wc/v3

El WebhookController recibe los eventos de WooCommerce (orden creada, stock actualizado, etc.) y los procesa con jobs en queue, que es exactamente para lo que Laravel es bueno. La comunicación va toda por la API REST de WooCommerce, que según la documentación oficial de WooCommerce cubre productos, órdenes, clientes, cupones, reportes y configuraciones.

Implementación práctica: setup completo

Para levantar el entorno desde cero en 2026:

# 1. Crear proyecto Laravel
composer create-project laravel/laravel mi-tienda-laravel

# 2. Instalar FrankenPHP (binario para Linux/Mac)
curl -L https://github.com/dunglas/frankenphp/releases/latest/download/frankenphp-linux-x86_64 -o frankenphp
chmod +x frankenphp

# 3. Instalar Pest
composer require pestphp/pest pestphp/pest-plugin-laravel --dev
php artisan pest:install

# 4. Instalar cliente WooCommerce
composer require automattic/woocommerce

# 5. Levantar el servidor
./frankenphp php-server --root public/

El punto de verificación después de cada paso es simple: levantá FrankenPHP y chequeá que Laravel responde en el puerto 8000. Si hay algún problema con permisos de directorios de storage, es el error más común en setups nuevos. chmod -R 775 storage bootstrap/cache resuelve el 90% de los casos.

Testing en CI/CD con tu setup

Pest se integra directo con GitHub Actions. Un workflow básico:

name: Tests
on: [push, pull_request]
jobs:
 test:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - name: Setup PHP
 uses: shivammathur/setup-php@v2
 with:
 php-version: '8.3'
 - run: composer install
 - run: php artisan pest

Para los browser tests necesitás Selenium o Chromium en el runner. Si estás en GitHub Actions, actions/browser-tools@v1 te lo configura automáticamente.

La cobertura de código con Pest usa la misma sintaxis de PHPUnit: php artisan pest --coverage --min=80 para exigir mínimo 80% de cobertura. Si el número cae, el CI falla y el deploy no pasa. No glamoroso, pero funciona.

Comparativa: approaches para mantener WooCommerce

Para equipos con experiencia en Laravel que heredan una tienda WooCommerce, la segunda fila de esa tabla es la que tiene más sentido. No estás reescribiendo el frontend ni abandonando WooCommerce como motor de e-commerce, estás poniendo la lógica que importa en un lugar donde podés testarla. Relacionado: migrar desde Shopify a WooCommerce.

Errores comunes en este setup

Error 1: usar las credenciales de administrador para la API REST. WooCommerce permite generar Consumer Key y Consumer Secret con permisos limitados (solo lectura, solo escritura, etc.). Muchos setups usan las credenciales de admin y después no saben por qué tienen un problema de seguridad. Generá claves específicas desde WooCommerce > Ajustes > Avanzado > API REST con el mínimo de permisos necesario.

Error 2: correr browser tests contra la tienda de producción. Los browser tests que crean órdenes o modifican el carrito deben correr siempre contra un ambiente de staging o una instalación WooCommerce dedicada para testing. Si lo corrés contra producción, estás creando órdenes reales (sí, en serio, le pasó a más de uno).

Error 3: asumir que la API REST de WooCommerce es estable entre versiones. WooCommerce versión 9.x introdujo cambios en algunos endpoints de la API v3 que rompieron integraciones sin aviso prominente en el changelog. Antes de actualizar WooCommerce, corré el suite de tests contra staging. Para eso está el CI/CD.

Error 4: ignorar el rate limiting de la API. Si tu app Laravel hace muchas llamadas a la API REST de WooCommerce en paralelo (por ejemplo, sincronizando inventario de 500 productos), podés saturar el servidor WordPress. Usá jobs en queue con delay entre requests o cacheá las respuestas con Redis. Laravel tiene todo esto integrado.

Podés profundizar en esto leyendo la experiencia de un Laravel engineer maintaining WooCommerce: I built a starter.

Preguntas Frecuentes

¿Cómo mantengo una tienda WooCommerce con Laravel sin reescribir todo desde cero?

Usás la API REST de WooCommerce para conectar Laravel con la tienda existente. WooCommerce expone endpoints para productos, órdenes, clientes y stock bajo /wp-json/wc/v3/. Tu app Laravel hace llamadas a esa API, procesa la lógica de negocio y puede disparar webhooks cuando ocurren eventos en la tienda. La tienda WooCommerce sigue funcionando normalmente en WordPress. Ya lo cubrimos antes en conectar con la comunidad WordPress.

¿Qué es Pest y en qué se diferencia de PHPUnit para proyectos Laravel?

Pest es un framework de testing PHP que corre sobre PHPUnit pero tiene una sintaxis más limpia y expresiva. En vez de clases con métodos que empiezan con test_, escribís funciones con it() y test(). Las aserciones usan expect() con encadenamiento fluido. Para proyectos Laravel, Pest tiene un plugin oficial con helpers específicos del framework como actingAs() y assertDatabaseHas().

¿Qué es FrankenPHP y para qué sirve con Laravel?

FrankenPHP es un runtime PHP moderno escrito en Go que reemplaza PHP-FPM. Para Laravel, su principal ventaja es el modo worker: la app arranca una vez y queda en memoria entre requests, eliminando el overhead de bootstrap de Laravel en cada petición. También simplifica el setup local porque viene con servidor HTTP integrado, sin necesitar Nginx o Apache por separado.

¿Cuál es la mejor forma de estructurar un proyecto Laravel para integrar con WooCommerce?

Separar los servicios por dominio: ProductService, OrderService, CustomerService en app/Services/WooCommerce/. Cada service encapsula las llamadas a la API REST y la lógica de transformación de datos. Los controllers de Laravel consumen esos services. Los webhooks de WooCommerce llegan a un WebhookController que dispara jobs en queue para procesamiento asíncrono.

¿Cómo hacer testing de navegador en aplicaciones Laravel para WooCommerce?

Pest tiene un plugin de browser testing que usa Chrome en modo headless para ejecutar flujos reales en el navegador. Configurás la URL de tu tienda WooCommerce de staging en el .env de testing, escribís tests con browse() que navegan la tienda, hacen clicks y verifican el resultado. Lo integrás en GitHub Actions con el runner de Chromium para que corra automáticamente en cada push.

Conclusión

Lo que este desarrollador publicó no es una «revolución» del stack WordPress, es una solución pragmática a un problema concreto: equipos Laravel que mantienen tiendas WooCommerce sin las herramientas de testing y estructura que ya conocen. FrankenPHP mejora el setup local y el rendimiento en producción. Pest hace que el testing PHP deje de ser una actividad que todos evitan. La API REST de WooCommerce ya existía y funciona bien.

Para equipos argentinos y latinoamericanos que trabajan con tiendas WooCommerce de clientes y tienen más experiencia en Laravel que en el ecosistema WordPress, este starter es un punto de partida real. Podés integrarlo con cualquier hosting que soporte PHP 8.3+. Si querés probar el setup localmente y después subirlo a un ambiente compartido, el hosting WordPress de Donweb soporta PHP 8.3 y tiene acceso SSH para configurar las variables de entorno del .env sin dramas.

El testing automatizado de flujos WooCommerce es lo que más valor aporta a mediano plazo. Mantener una tienda sin tests es siempre apostar a que nada se rompió con la última actualización. Con Pest y browser testing integrado al CI, esa apuesta desaparece.

Fuentes

• FrankenPHP – Documentación oficial del runtime PHP moderno
• Pest PHP – Documentación oficial del framework de testing
• Laravel – Documentación oficial del framework
• WooCommerce – Documentación oficial y API REST