Por qué Maison Code habla de esto

En Maison Code Paris, actuamos como la conciencia arquitectónica de nuestros clientes. A menudo heredamos stacks “modernos” construidos sin una comprensión fundamental de la escala.

Discutimos este tema porque representa un punto de inflexión crítico en la madurez de la ingeniería. Implementarlo correctamente diferencia un MVP frágil de una plataforma resistente de nivel empresarial.

El miedo al despliegue

Todo ingeniero de software conoce esa sensación. Es viernes a las cuatro de la tarde. Acaba de fusionar una solicitud de extracción. El proceso de implementación se vuelve verde. Deberías estar feliz. Pero estás sudando. “¿Rompí el flujo de pago?” “¿Rompí el restablecimiento de contraseña?” “¿Probé el menú móvil en Safari?” Si confía en las Pruebas manuales (haciendo clic usted mismo en el sitio web), vivirá en un estado constante de miedo. Los humanos son terribles en las pruebas de regresión. Nos aburrimos. Extrañamos cosas. Probamos el “Happy Path” y nos olvidamos de los casos extremos. A medida que crece el código base, el tiempo necesario para probarlo manualmente crece linealmente. Al final, dejas de realizar pruebas. Ahí es cuando los errores se filtran a producción. Y cuando se filtran errores, se pierden ingresos. Pierdes la confianza. Las pruebas automatizadas son la cura para este miedo. Convierte la implementación de un “evento de alto riesgo” en un “no evento”.

Por qué Maison Code analiza las pruebas automatizadas

En Maison Code, trabajamos con marcas de lujo de alto riesgo y plataformas de comercio electrónico de mucho tráfico. Nuestros clientes generan miles de euros por minuto durante los picos de ventas (Black Friday, Navidad). Un error “menor” en el flujo de pago no es un inconveniente; es una catástrofe financiera. Hemos visto marcas perder €50 mil en una hora porque un botón “AddToCart” estaba cubierto por un error de índice Z en el iPhone 12. Hablamos de pruebas automatizadas porque La estabilidad es ingreso. No vendemos “código”. Vendemos “Fiabilidad”. Implementar una suite E2E sólida es a menudo lo primero que hacemos cuando auditamos el código base heredado de un cliente. Detiene el sangrado y nos permite refactorizar con confianza.

1. La pirámide de pruebas: un marco estratégico

Mike Cohn popularizó el concepto de “Pirámide de pruebas” y sigue siendo el estándar de oro para la estrategia de pruebas. Define la distribución ideal de pruebas en su suite.

Pruebas unitarias (70%):
- Alcance: Funciones o clases individuales.
- Velocidad: Milisegundos.
- Costo: Barato.
- Herramienta: Jest, Vitest.
- Ejemplo: agregar(2, 2) === 4.
Pruebas de Integración (20%):
- Alcance: Interacciones entre componentes (por ejemplo, el padre pasa accesorios al niño).
- Velocidad: Segundos.
- Costo: Medio.
- Herramienta: Biblioteca de pruebas de React.
Pruebas de extremo a extremo (E2E) (10%):
- Alcance: flujos de usuario completos en un navegador real.
- Velocidad: Minutos.
- Costo: Caro (computación pesada).
- Herramienta: Dramaturgo, Cypress.

En este artículo, nos centraremos en la cima de la pirámide: Pruebas E2E. ¿Por qué? Porque proporciona el Coeficiente de Confianza más alto. Una prueba unitaria puede pasar incluso si el botón “Enviar” está oculto por un error de “índice z” de CSS. Una prueba E2E fallará porque intenta hacer clic en el botón. Si una prueba E2E dice “Artículo comprado por el usuario”, puede estar 99,9% seguro de que los usuarios pueden comprar artículos.

2. La herramienta elegida: el dramaturgo

Durante una década, el Selenio fue el estándar. Era lento, estaba basado en Java y notoriamente inestable. Luego vino Ciprés. Fue una mejora enorme, con una excelente experiencia para el desarrollador, pero tenía limitaciones arquitectónicas (ejecución dentro del entorno limitado del navegador, soporte limitado para múltiples pestañas). Hoy en día, el estándar de la industria es Playwright (de Microsoft). ¿Por qué dramaturgo?

Velocidad: ejecuta pruebas en paralelo en múltiples procesos de trabajo.
Confiabilidad: Tiene “Espera automática”. Espera a que los elementos sean procesables antes de interactuar. No más “dormir (1000)”.
Navegador múltiple: prueba de forma nativa en Chromium, Firefox y WebKit (Safari).
Seguimiento: Graba un video completo y un seguimiento DOM de cada falla, lo que hace que la depuración sea trivial.

3. Implementación: prueba de un flujo de pago

Veamos un ejemplo del mundo real. Queremos probar que un usuario invitado puede comprar un producto.

// pruebas/checkout.spec.ts
importar {prueba, esperar} de '@dramaturgo/prueba';

test.describe('Flujo de pago', () => {
  
  // Aislar el entorno de prueba
  test.beforeEach(async ({ página }) => {
    //Restablecer cookies/almacenamiento
    espere página.context().clearCookies();
  });

  test('El usuario invitado puede comprar un artículo', async ({ página }) => {
    // 1. Navegación
    console.log('Navegando a la página del producto...');
    await page.goto('/productos/camisa-de-seda');
    await expect(page).toHaveTitle(/Camisa de seda/);
    
    // 2. Añadir al carrito
    // Utilice localizadores orientados al usuario (rol, etiqueta, texto)
    // Evita selectores de CSS como '.btn-primary' (frágil)
    espere page.getByRole('botón', { nombre: 'Agregar al carrito' }).click();
    
    // 3. Verificar el cajón del carrito
    const cartDrawer = page.getByTestId('cajón-carrito');
    await expect(cartDrawer).toBeVisible();
    await expect(cartDrawer).toContainText('Camisa de seda');
    
    // 4. Proceder al pago
    espere page.getByRole('enlace', { nombre: 'Pagar' }).click();
    await expect(page).toHaveURL(/.*\/checkout/);
    
    // 5. Complete el formulario (pago simulado)
    await page.getByLabel('Email').fill('test-bot@maisoncode.paris');
    await page.getByLabel('Nombre').fill('Prueba');
    await page.getByLabel('Apellido').fill('Bot');
    espere page.getByLabel('Dirección').fill('123 Test St');
    
    // 6. Pago (simulación de rayas)
    // En estricto E2E, podríamos usar una tarjeta de prueba Stripe.
    await page.getByLabel('Número de tarjeta').fill('4242 4242 4242 4242');
    await page.getByLabel('Expiry').fill('30/12');
    espere page.getByLabel('CVC').fill('123');
    
    // 7. Enviar
    espere page.getByRole('botón', { nombre: 'Pagar ahora' }).click();
    
    // 8. Afirmar el éxito
    // Aumentar el tiempo de espera porque el procesamiento de pagos lleva tiempo
    await expect(page.getByText('Gracias por su pedido')).toBeVisible({ timeout: 15000 });
  });

});

4. Manejo de la “descamación” (El asesino silencioso)

Una Prueba Flaky es una prueba que pasa el 90% de las veces y falla el 10% de las veces, sin ningún cambio en el código. La descamación es el enemigo. Si los desarrolladores dejan de confiar en las pruebas (“Oh, simplemente vuelva a ejecutarlas, es inestable”), el conjunto de pruebas se vuelve inútil.

Causas comunes:

Latencia de red: la API tarda 5,1 segundos cuando el tiempo de espera es de 5 segundos.
Animación: hacer clic en un botón mientras aún se está deslizando.
Contaminación de datos: la Prueba A elimina un usuario que la Prueba B necesita.

Soluciones:

Burla (Interceptación de Red): En lugar de llamar a la API Contentful real (que puede ser lenta), intercepte la solicitud y devuelva un JSON estático.
```
espere página.ruta('**/api/productos', ruta => {
  route.fulfill({ ruta: 'mock-data/products.json' });
});
```
Esto hace que la prueba sea 10 veces más rápida y 100% determinista.
Reintentos: Configure CI para reintentar las pruebas fallidas automáticamente. reintentos: 2. Si pasa al reintentar, es inestable, pero al menos no bloquea la implementación.

5. Prueba de regresión visual (Pixel Perfect)

El dramaturgo comprueba la funcionalidad (“¿Se puede hacer clic en el botón?”). No comprueba la estética (“¿El botón es rosa?”). Si elimina accidentalmente main.css, es posible que Playwright aún pase (se puede hacer clic en el botón, simplemente es invisible). Pruebas de regresión visual (Percy / Chromatic / Playwright Snapshots) soluciona este problema. espera esperar (página).toHaveScreenshot();

Tome una captura de pantalla de la página.
Compárelo con la “Imagen Dorada” (Línea de Base).
Si los píxeles difieren en > 1 %, no pasa la prueba. Esto detecta “Regresiones CSS” que ninguna prueba funcional podría detectar.

6. Acciones de GitHub: el guardián automatizado

No ejecuta pruebas en su computadora portátil. Los ejecuta en CI (integración continua). Cada vez que ingresas a GitHub, se ejecuta un flujo de trabajo.

# .github/workflows/e2e.yml
nombre: Dramaturgo E2E
en:
  empujar:
    sucursales: [principal]
  solicitud_pull:
    sucursales: [principal]

trabajos:
  prueba:
    minutos de tiempo de espera: 60
    se ejecuta en: ubuntu-latest
    pasos:
      - usos: acciones/checkout@v3
      - usos: acciones/setup-node@v3
        con:
          versión de nodo: 18
      - nombre: Departamentos de instalación
        ejecutar: npm ci
      - nombre: Instalar navegadores
        ejecutar: instalación de dramaturgo npx --with-deps
      
      - nombre: Ejecutar dramaturgo
        ejecutar: prueba de dramaturgo npx
        entorno:
          CI: verdadero
          BASE_URL: ${{ github.event.deployment.payload.web_url }} // Pruebe la URL de vista previa de Vercel

      - nombre: Cargar informe
        usos: acciones/upload-artifact@v3
        si: siempre()
        con:
          nombre: informe del dramaturgo
          ruta: informe-dramaturgo/

7. El costo de la CI (optimización)

Ejecutar 500 pruebas E2E en cada confirmación es costoso (minutos de GitHub Actions). Estrategias de optimización:

Fragmentación: divide las pruebas en 10 máquinas, lo que hace que se ejecuten 10 veces más rápido. Prueba de dramaturgo npx --shard=1/10.
Solo proyectos afectados: use Nx o Turbo para ejecutar pruebas solo para aplicaciones que cambiaron.
Pruebas de humo para RP: ejecute un pequeño subconjunto (ruta crítica) en RP. Ejecute el paquete completo en Main.

8. Conclusión

Las pruebas automatizadas no son “trabajo extra”. Es el trabajo. Es la diferencia entre un prototipo y un producto. Es la diferencia entre “espero que funcione” y “sé que funciona”. Empiece hoy. Escribe UNA prueba. La prueba de inicio de sesión. Luego la prueba de pago. Pronto dormirás mejor por la noche.

¿Liberaciones que causan pánico?

Diseñamos conjuntos de pruebas E2E automatizadas utilizando Playwright que detectan errores antes que los usuarios.

Automatizar mi control de calidad. Contrate a nuestros arquitectos.