Cómo crear tests en Angular enfocados en el comportamiento del usuario

¿Quieres que tus tests de Angular pasen de ser una lista de chequeo inútil a una garantía real de calidad?

Poca gente lo hace bien: usan la IA para generar código, no para protegerlo. Eso cambia hoy.

Resumen rápido (lectores con prisa)

Qué es: Un playbook práctico para usar IA en la generación de pruebas unitarias de Angular centradas en comportamiento.

Cuándo usarlo: Al crear componentes nuevos, al refactorizar suites legacy o al buscar escenarios límite que los humanos suelen olvidar.

Por qué importa: La IA puede escribir tests, pero sin contexto y prompts adecuados produce pruebas frágiles que fallan con cualquier refactor.

Cómo funciona (resumen): Pedir “comportamiento” en lugar de “tests”, enviar componente + package.json + restricciones, usar prompts versionados y validar los resultados en CI.

La IA puede escribir tests. Pero la diferencia entre pruebas útiles y basura es el prompt, el contexto y tu criterio. Aquí te dejo el playbook completo: prompts listos para pegar, ejemplos prácticos, cómo validar lo que devuelve la IA y cómo encajar todo en tu CI. Sin teoría aburrida. Directo, efectivo y aplicable ahora mismo.

Tiempo estimado de lectura: 7 min

Ideas clave

No pidas “tests”: pide comportamiento y obliga a la IA a interactuar con la UI.
Provee contexto: componente (ideal: Standalone), package.json con versiones y constraints de librerías críticas.
Prompts reproducibles: versiona los prompts y úsalos en CI con revisión humana.
Validación: exige render() de @testing-library/angular, consultas por rol/label y userEvent para interacciones.
Automatiza con cautela: IA sugiere tests, humanos revisan antes de merge; usa canary y jobs que verifiquen cobertura.

Tabla de contenidos

Introducción

Primero: la regla de oro. No pidas “tests”. Pide comportamiento. Obliga a la IA a interactuar con la UI, no con las propiedades internas del componente. Si no lo haces, tendrás tests que rompen con cualquier refactor.

Primero: la regla de oro

No pidas “tests”. Pide comportamiento. Obliga a la IA a interactuar con la UI, no con las propiedades internas del componente. Si no lo haces, tendrás tests que rompen con cualquier refactor.

¿Qué necesitas enviar a la IA?

El componente (preferible: Standalone Component).
package.json con versiones (Angular, RxJS, TypeScript).
Lista corta de libs críticas que no puedes romper.
Breve “constraints” (ej.: no tocar auth module).

Prompts que funcionan (copiar y pegar)

1) Prompt para generar tests base (Behavior-first)

Usa este cuando tienes componente nuevo y quieres la suite inicial.

System:
“Eres un Senior Angular Testing Engineer. Genera pruebas robustas enfocadas en comportamiento del usuario. Usa Jest y @testing-library/angular. Prioriza getByRole/getByLabelText, usa @testing-library/user-event para interacciones, no accedas a propiedades internas del componente. Devuelve solo el archivo de test.”

User:
“Write unit tests using Jest and Testing Library for this Angular standalone component using signals. Focus on behavior not implementation. Use screen for queries and prioritize accessibility roles (getByRole, getByLabelText). Do not test internal component properties or methods directly.

[PEGA EL COMPONENTE AQUI]
package.json: [VERSIONES]
constraints: [LIBS_CRITICAS]”

Por qué funciona:

Forzamos uso de Testing Library.
Evitamos TestBed verboso.
Tests centrados en lo que el usuario ve o hace.

2) Prompt para mejorar tests existentes (Refactoring)

Toma suites legacy y las vuelve mantenibles.

System:
“Eres un Senior Test Refactorer. Reescribe la suite para eliminar acoplos a la implementación, modernizar APIs y mejorar robustez.”

User:
“Review and refactor the following Jest test suite for an Angular component. Replace fireEvent with @testing-library/user-event, remove any assertions about component internals, ensure tests use render from @testing-library/angular, and include accessibility checks (roles/labels). Output: refactored test file only.

[PEGA LA SUITE LEGACY AQUI]”

Por qué funciona:

Convierte tests frágiles en pruebas de comportamiento.
Mejora fiabilidad frente a refactors.

3) Prompt para detectar edge cases (Generador de escenarios destructivos)

Esto detecta lo que los humanos olvidan.

System:
“Eres un Senior QA Engineer con experiencia en concurrency y edge cases.”

User:
“Analyze this Angular component. The happy path is covered. Identify at least 4 missing edge cases (e.g., rapid double clicks, null/undefined signal inputs, async race conditions, API errors) and write Jest + Testing Library tests for each case. Use realistic mocks and include timing control (jest.useFakeTimers() / waitFor). Output: tests only.”

Por qué funciona:

Fuerza a la IA a pensar en fallos reales.
Te entrega pruebas que aumentan la resiliencia del sistema.

Ejemplo práctico: prompt + resultado esperado

Prompt que puedes pegar tal cual:
“Write unit tests using Jest and Testing Library for this Angular standalone component using signals. Focus on behavior not implementation.”

Componente (ejemplo resumido):

@Component({ standalone: true, template: `...` })
export class SearchComponent {
  query = signal('');
  results = toSignal(this.api.search(this.query()));
  // ...
}

Qué pedirle que incluya en la respuesta:

render(…) desde @testing-library/angular.
mocks de servicio (jest.fn()).
pruebas con userEvent.type/click.
assertions sobre texto visible o roles.
tests que simulen errores de la API y tiempos (jest.useFakeTimers).

Fragmento de test ideal (lo que debes esperar)

import { render, screen } from '@testing-library/angular';
import userEvent from '@testing-library/user-event';
import { SearchComponent } from './search.component';
import { ApiService } from './api.service';

test('shows results after successful search', async () => {
  const apiMock = { search: jest.fn().mockResolvedValue([{ id:1, name:'foo' }]) };
  await render(SearchComponent, { providers: [{ provide: ApiService, useValue: apiMock }] });
  await userEvent.type(screen.getByRole('textbox', { name: /search/i }), 'foo');
  expect(await screen.findByText('foo')).toBeInTheDocument();
});

Cómo validar lo que te devuelve la IA (Checklist rápido)

¿Usó render() en lugar de TestBed? ✔
¿Consultas basadas en roles/labels, no selectores CSS? ✔
¿Usó userEvent para simular interacciones? ✔
¿Incluye mocks por inyección (providers) en la render? ✔
¿Tiene tests para errores y timing? ✔
¿Los tests fallan cuando introduces un bug intencionado? (Rompe la lógica y correlos) ✔

Integración CI: automatiza y no confíes ciegamente

GitHub Action que llama a la IA en PRs y adjunta tests sugeridos.
Pero obliga a un humano a revisar antes de merge.
Añade job de “fail on new tests without coverage” para evitar tests vacíos.
Canary: despliega cambios de tests a una rama canary y ejecuta e2e.

Errores comunes de la IA y cómo arreglarlos

Hallucinations ARIA: la IA busca roles que tu template no tiene. Solución: añade line “Ensure tests use fallback queries (getByText) if role not present” al prompt.
Falsos positivos: test pasa pero no cubre comportamiento. Solución: modifica el componente para que fallo intencional y asegura que test cae.
Control Flow nuevo (@if/@for): la IA puede no simular bien la carga diferida. Solución: pide explicitamente “handle Control Flow directives: use waitFor/findBy” en el prompt.

Mejor práctica: versiona los prompts

Sí. Versiona los prompts como si fueran código. Prompt-v1.0, prompt-v1.1, changelog. Así vuelves reproducible la generación de tests y puedes auditar cambios.

Plantilla de prompt “PRO” para equipos

System:
“Eres un Senior Angular Test Engineer. Responde con JSON { summary, issues[], tests: string }.”

User:
“Generate tests for [FILE]. Constraints: Angular 19, Signals, Jest, @testing-library/angular, do not touch files outside test. Provide unified diff and one unit test file. package.json: […]”

Pedir diff es crucial si quieres aplicar el parche automático en CI.

Conexión con ebook y cursos (CTA)

Si este flujo te parece útil, lo que separa a los que solo leen de los que producen calidad es el proceso reproducible. En mi ebook y curso te doy:

Plantillas de prompts versionadas.
GitHub Action listo para pegar.
Ejemplos reales de refactor y tests para migrar RxJS → Signals.

Quieres que te lo deje listo para pegar en tu repo?
Responde: “QUIERO EL KIT” y te paso:

Action + workflow para PR reviews.
10 prompts optimizados (generar, refactor, edge cases).
Ejemplos de tests reales y un checklist de validación automática.

Cierre con estocada final

Generar tests con IA es fácil. Generar tests que importen es difícil. La diferencia está en cómo preguntas y cómo validas. Hazlo bien y tu código se vuelve más robusto. Hazlo mal y tendrás más trabajo del que crees. Tú decides.

Dominicode Labs

Si quieres sistemas, agentes o workflows que automaticen generación y revisión de tests, puedes continuar explorando recursos y prototipos en Dominicode Labs. Es una extensión natural del flujo descrito aquí para equipos que quieren automatizar sin perder control.

FAQ

¿Por qué pedir comportamiento en lugar de tests?
¿Qué pasa si la IA inventa roles ARIA que no existen?
¿Cómo evito tests que pasan pero no detectan regresiones?
¿Debo automatizar merges de tests generados por la IA?
¿Qué debo incluir en el package.json que envío a la IA?
¿Con qué frecuencia versiono los prompts?

¿Por qué pedir comportamiento en lugar de tests?

Porque las pruebas centradas en comportamiento interactúan con la UI igual que un usuario. Así son resilientes frente a refactors internos que cambian implementaciones pero no la experiencia.

¿Qué pasa si la IA inventa roles ARIA que no existen?

Añade una línea al prompt que indique “Ensure tests use fallback queries (getByText) if role not present”. Validar manualmente y ejecutar la suite en CI detectará esos hallucinations.

¿Cómo evito tests que pasan pero no detectan regresiones?

Introduce bugs intencionales en una copia local del componente y asegúrate de que los tests sugeridos fallan. Añade jobs en CI que verifiquen que tests nuevos aporten cobertura real.

¿Debo automatizar merges de tests generados por la IA?

No sin revisión humana. Automatiza la generación y las pruebas en una rama canary, pero requiere aprobación humana antes de merge.

¿Qué debo incluir en el package.json que envío a la IA?

Incluye versiones de Angular, RxJS y TypeScript, además de las dependencias críticas que no puedes romper. Eso ayuda a la IA a generar pruebas compatibles con tu stack.

¿Con qué frecuencia versiono los prompts?

Versiona cada cambio significativo: Prompt-v1.0, v1.1, etc. Haz changelog. Cada cambio en el prompt puede alterar la generación y debe ser auditado como código.