Pruebas para código generado con IA: por dónde empezar

Para que el próximo mensaje al agente no rompa una app hecha con IA, empieza con tres a cinco pruebas de punta a punta para los flujos más importantes (registro, inicio de sesión, la acción principal, el pago) y suma pruebas unitarias pequeñas para la lógica que se rompe una y otra vez. Córrelas antes de aceptar cada cambio y deja escrito en las instrucciones del agente que una tarea no está terminada hasta que pasen. En una app típica con React, Vite o Next.js, Playwright cubre los flujos en el navegador y Vitest la lógica.

En esta guía verás por qué los cambios con IA rompen cosas que funcionaban, qué pruebas dan más protección con menos esfuerzo, cómo instalarlas, cómo conseguir que el agente escriba pruebas que valgan la pena y cómo hacer que se ejecuten solas.

¿Por qué cada nuevo mensaje rompe algo que ya funcionaba?

El agente solo sabe qué significa "funciona" para la tarea que tiene delante. Si le pides cambiar la página de precios, nada le avisa que el checkout que tocó de paso antes funcionaba. Una persona del equipo lo recordaría; el agente empieza cada sesión sin memoria de lo que probaste a mano la semana pasada.

Las pruebas son esa memoria, por escrito. No hacen más listo al agente: hacen evidente, en menos de un minuto, que algo que cambió rompió otra cosa.

¿Qué pruebas agrego primero?

Las más baratas que cubran las fallas más caras.

Al principio, sáltate las capturas completas de páginas y las pruebas de componentes que solo muestran datos. Se rompen seguido por motivos inofensivos y acostumbran a todos a ignorar los fallos.

¿Cómo instalo Playwright para los flujos principales?

1. En la carpeta del proyecto, ejecuta npm init playwright@latest y acepta las opciones por defecto. Crea un archivo de configuración y una prueba de ejemplo.
2. Levanta la app (npm run dev) y graba un flujo con npx playwright codegen http://localhost:5173. Inicia sesión como lo haría un usuario; Playwright escribe los pasos por ti.
3. Limpia la grabación hasta que compruebe un resultado y no solo haga clics:

import { test, expect } from '@playwright/test';

test('un usuario inicia sesión y llega al panel', async ({ page }) => {
  await page.goto('http://localhost:5173/login');
  await page.getByLabel('Email').fill(process.env.TEST_USER_EMAIL!);
  await page.getByLabel('Password').fill(process.env.TEST_USER_PASSWORD!);
  await page.getByRole('button', { name: 'Sign in' }).click();
  await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();
});

4. Ejecútala con npx playwright test.

Cambia las etiquetas y la URL por las de tu app; si tu interfaz está en español, usa los textos tal como aparecen en pantalla. Usa una cuenta de prueba en una base de pruebas, nunca el acceso de un cliente real. La guía de inicio de Playwright explica navegadores, configuración y cómo correrlo en integración continua.

¿Cómo agrego pruebas unitarias con Vitest?

Las pruebas unitarias sirven para lógica pura: una función que recibe datos y devuelve un resultado. Instala con npm install -D vitest y agrega "test": "vitest run" en los scripts de package.json. Luego escribe la prueba junto al código:

import { describe, it, expect } from 'vitest';
import { invoiceTotal } from './invoiceTotal';

describe('invoiceTotal', () => {
  it('aplica el descuento antes del impuesto', () => {
    expect(invoiceTotal({ subtotal: 100, discount: 10, taxRate: 0.2 })).toBe(108);
  });

  it('nunca queda por debajo de cero', () => {
    expect(invoiceTotal({ subtotal: 20, discount: 50, taxRate: 0.2 })).toBe(0);
  });
});

Si la lógica que te importa está enterrada dentro de un componente enorme, pide al agente que primero la saque a su propia función sin cambiar su comportamiento, y prueba esa función.

¿Cómo hago que la IA escriba pruebas que sirvan?

Los agentes escriben pruebas rápido, pero no siempre buenas. Unas pocas instrucciones cambian mucho el resultado.

1. Fija el comportamiento actual antes de tocar nada. "Escribe pruebas que describan cómo se comporta hoy invoiceTotal. No cambies la función." Esa es tu red para el cambio que viene después.
2. Pide el caso que falla. "Incluye una prueba con un cupón vencido y otra con una cantidad negativa."
3. Comprueba que la prueba puede fallar. Rompe el código a propósito, por ejemplo cambia + por -, y confirma que la prueba se pone en rojo. Una prueba que pasa pase lo que pase no protege nada.
4. Prohíbe editar pruebas para que pasen. Agrega a tus reglas: "Nunca cambies ni borres una prueba existente para que pase. Si una prueba parece incorrecta, detente y avísame." Revisa los cambios buscando .skip, comprobaciones más laxas o archivos de prueba borrados.
5. Lee lo que se comprueba. Una prueba que solo verifica que "la página cargó" no va a detectar un total equivocado.

¿Cómo hago que las pruebas se ejecuten siempre?

Las pruebas que solo corren cuando alguien se acuerda no frenan nada. Tres capas:

• En las instrucciones del agente. "Antes de decir que terminaste, ejecuta npm test y npx playwright test e informa el resultado." Mira cómo escribir reglas de Cursor para un proyecto real.
• Antes de fusionar. Córrelas tú en la rama. No te quedes con la palabra del agente.
• En cada push. Un flujo pequeño de GitHub Actions en .github/workflows/tests.yml:

name: tests
on: [push, pull_request]
jobs:
  unit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
      - run: npm ci
      - run: npm test

Empieza con las pruebas unitarias en ese flujo y suma Playwright cuando tengas la cuenta y la base de pruebas listas para él.

Respuestas rápidas

¿Cuántas pruebas necesito para notar la diferencia? Tres buenas pruebas de punta a punta sobre tus flujos principales ya atrapan la mayoría de los "el último mensaje rompió el login".

¿Las pruebas me van a frenar al construir con IA? Un poco en cada cambio, y mucho menos que depurar un checkout roto después del lanzamiento.

¿Puedo agregar pruebas a una app hecha en Lovable o Bolt? Sí, en cuanto el código esté en GitHub. Las pruebas viven en el repositorio y se ejecutan contra la app como en cualquier otro proyecto.

¿Y si el código está demasiado enredado para probarlo? Empieza por las pruebas de punta a punta, que no dependen de cómo está organizado el código por dentro. Te dan la red para ordenarlo después.

¿Quieres ayuda para armar esa red de seguridad?

Si Bolt rompe la app con cada cambio o tu proyecto de Cursor vuelve a fallar en lo mismo, las pruebas suelen ser el primer arreglo. Combínalas con una rutina para revisar código generado por IA. Si prefieres que alguien prepare las primeras pruebas contigo, mira nuestra ayuda con proyectos de Cursor o el mantenimiento de software, o escríbenos.