Las pruebas de fábrica

Un equipo sin pruebas no necesita un consejo: necesita una suite que ya corra. kbspec resuelve el día cero en tres comandos.

1. `kb pruebas estrategia` — con qué se escriben las unitarias

Lee los manifiestos reales de cada proyecto (nunca el nombre de la carpeta) y decide: adoptar lo que la mayoría ya usa, declarar que está partido, o recomendar si no hay nada — xUnit para .NET (es lo que genera dotnet new y tiene una sola forma de escribir cada cosa), Vitest para Angular (el runner oficial desde Angular 21; Karma está retirado). Y al proponer desde cero, imprime los comandos de arranque:

Propuesta: **xUnit** — es lo que genera `dotnet new` por defecto…
  $ dotnet new xunit -o pruebas/<Proyecto>.UnitTests
  $ dotnet add pruebas/<Proyecto>.UnitTests reference <ruta/Proyecto.csproj>
  $ dotnet add pruebas/<Proyecto>.UnitTests package FluentAssertions
  $ dotnet test

Con --aplicar, la decisión queda en el estándar del tipo — el documento que el agente lee antes de escribir cualquier prueba.

2. `kb pruebas preparar` — el proyecto E2E de la app, sembrado desde la ficha

Las E2E de una app viven en su proyecto E2E: <raíz de la app>/pruebas-e2e/, un proyecto Node propio —ni mezclado con el package.json de Angular ni adentro del código— que la ficha declara en «Dónde viven las pruebas». Las pruebas de cada requerimiento van en e2e/<TICKET>/; en una app de módulos federados (micro-frontends), si la ficha pone <módulo> en esa ruta, en e2e/<módulo>/<TICKET>/, con un proyecto de Playwright por módulo (--project <módulo>). kb pruebas preparar lo siembra la primera vez (kb pruebas init), instala las versiones que kbspec probó con npm ci y deja el navegador que lanza en esa máquina:

Archivo	Qué trae
`package.json` · `tsconfig.json` · `.gitignore`	Playwright y el linter fijados (nunca `@latest`); el `.env`, las sesiones y el estado de la máquina, fuera de git
`AGENTS.md`	Las reglas para cualquier agente: qué leer antes de escribir, dónde va cada cosa, cómo se escribe una prueba, cuándo está hecha
`.env.ejemplo`	Una línea por usuario de la ficha, con la variable de su clave
`playwright.config.ts`	Proyectos `preflight → setup → pruebas` (+ `humo` a pedido); la URL y el certificado de cada ambiente; `webServer` en local con las dependencias de la ficha y después la app, cada una esperada en su ruta de salud y reutilizada si ya está arriba; trace en cada falla local; reportes HTML, JSON y JUnit
`e2e/preflight.setup.ts`	Antes de todo: el navegador, la URL con el mismo certificado que las pruebas, Node contra la app, lo que la app necesita para responder (el backend y los APIs de la ficha, también los que se consumen de un ambiente), la pantalla de login. Si falla, no corre nada más y dice por qué — una causa, no cuarenta pruebas rojas
`e2e/auth.setup.ts`	Login una vez por usuario: formulario (con país o dominio), token por URL, Windows, SSO (lo hace la persona: `kb pruebas login --asistido`), API. La sesión se reusa solo si sirve: se prueba
`e2e/fixtures.ts`	El `test` de las pruebas: `test.use({ alias })` pone la sesión de ese usuario (y su sessionStorage), cierra los diálogos que la ficha declara y registra la red; `app` es la app ya abierta —la página, o el iframe cuando se entra desde un portal—
`e2e/humo.spec.ts`	Llega a cada pantalla con cada usuario y deja su captura y su árbol de accesibilidad
`e2e/modelo-condiciones.ts`	El modelo que las E2E imitan: feliz, falla, permiso denegado y el ejemplo de una regla, cada uno afirmando su oráculo del 02
`e2e/utiles/`	`irA` (la receta de la ficha), `esperarRespuesta` (la API lenta, «primero la red»), controles de PrimeNG, Material, Kendo, WebForms, datos con prefijo `E2E-<TICKET>-`
`e2e/kb.config.json`	Generado desde la ficha (`kb pruebas sync`): login, ambientes, mapa de navegación, usuarios, diálogos, tiempos, test id, dependencias

Lo que es de kbspec lleva en su primera línea una marca con su versión: kb pruebas sync lo actualiza mientras nadie lo edite —así un defecto del kit se corrige en todos los repositorios—, y lo que el equipo editó queda del equipo. Jamás siembra un segundo proyecto Playwright, y la compuerta niega escribir una prueba fuera de este.

`kb pruebas levantar` — el ambiente arriba una vez, no en cada corrida

El webServer de Playwright levanta lo que falta en cada corrida —uno detrás de otro, cada uno cuando el anterior responde— y lo baja al terminar: con dos APIs y un frontend, cada corrida paga el arranque entero, con la compilación de cada uno. kb pruebas levantar lo levanta una vez y lo deja arriba mientras se trabaja:

las dependencias de la ficha arrancan juntas —el backend y los APIs— y después la app; los dotnet run que compilan, de a uno (dos compilaciones a la vez sobre los mismos proyectos chocan);
cada una se da por arriba cuando responde su ruta de salud —la URL más «Listo cuando responde»—, siguiendo las redirecciones: la misma URL que espera Playwright, que por eso la encuentra arriba y la reutiliza;
lo que se consume de un ambiente publicado (seguridad, catálogos) se verifica, no se levanta, y el preflight frena con su nombre si no responde;
con un requerimiento abierto, solo lo común y lo de sus módulos —lo que lista el plan de pruebas—; --modulo todos levanta todo;
si algo no arranca, dice cuál, lo último de su log y el arreglo (el puerto ocupado, el certificado de .NET, el comando que no existe).

Queda en primer plano, como docker compose up o aspire run: Ctrl+C lo baja, y cerrar la terminal también. Un agente o un script usa --fondo (vuelve cuando todo responde; sale con 3 si una dependencia de otro ambiente no contesta) y --bajar. En el pipeline no se levanta nada: las pruebas corren contra el ambiente desplegado.

`kb pruebas validar` — la base, probada antes de gastar un token

Las E2E fallaban por el ambiente y no por la prueba: el navegador que no arranca, el certificado, la app que no levanta, el login, la pantalla que no se alcanza. kb pruebas validar lo prueba en orden, a pedido del desarrollador: lo que la ficha dice de la app → la máquina → el preflight → el login de cada usuario → cada pantalla con cada usuario que la ve. Corta en el primer rojo con su arreglo:

✗ login · qa_consulta — El login de «qa_consulta» no entró: la app dice «Usuario o
  contraseña incorrectos». Revisá su clave (KB_CLAVE_QA_CONSULTA en el .env del kit)…
✗ pantalla · qa_admin · Clientes — irA(«Clientes»): el paso 1 de la receta
  (link:Clientez) no aparece. Lo que se puede clickear ahí: link:Inicio, link:Clientes…

Y kb pruebas demo corre la misma base contra una app de prueba que trae kbspec —con su propio login, y abierta desde un portal en un iframe con un token—: si la demo pasa y la app no, el problema está en la app o en su ficha, no en la máquina. kb pruebas mapa arma un borrador del Mapa de navegación desde el código (rutas de Angular, menús, Web.sitemap).

Apps a las que se llega desde otra

Hay apps que no empiezan en su login: se entra a un portal, se elige módulo y perfil, y el portal abre la app en un iframe pasándole un token. La ficha de la app lo declara una vez —«Entrada a la app»: desde qué app se entra, qué se elige (con los datos de cada usuario: ${modulo}, ${perfil}), en qué iframe vive y qué se ve cuando cargó— y el login va en la ficha del portal. El kit la recorre solo antes de cada prueba —descubre si alcanza con volver a abrir la página que contiene la app o hay que repetir los pasos, cuando el token sirve una sola vez— y la prueba recibe la app ya abierta. Nadie vuelve a escribir cómo se entra.

`kb pruebas grabar` — recorrer en vez de describir

El desarrollador abre el grabador de Playwright, entra como siempre, llega a la app o al módulo y recorre las pantallas del requerimiento, afirmando lo que el 02 dice que tiene que verse. Al cerrar el navegador, kbspec separa lo grabado:

Lo grabado	A dónde va
El login (los campos, el botón, lo que se ve al entrar)	«Autenticación de las pruebas» de la ficha — la del portal, si se entró por otro lado
El portal, el módulo, el perfil, el iframe	«Entrada a la app», con los datos de cada usuario en vez de los del que grabó
Cada pantalla y cómo se llega	«Mapa de navegación», y quién la ve cuando el 02 dice que un rol no puede
Lo que se hizo y se afirmó en cada pantalla	`pruebas/grabacion-<TICKET>.md` y `pruebas/grabaciones/` en el expediente: cada grabación con su usuario y su rol

Lo que la ficha ya tenía se compara: lo distinto se dice y no se pisa. Las pruebas salen de los criterios, no de la grabación: con el brief aprobado, una por fila —también las que sumó el desarrollador— con su usuario, los datos que dice el criterio y el resultado del 02; la grabación pone el camino y los controles que se ejecutaron de verdad, y lo que se afirmó al grabar y el 02 no pide queda como comentario.

Se graba las veces que haga falta: con el perfil que ve un menú y con el que no, la falla, lo que faltó (--para <condición>). Todas las grabaciones vigentes se usan y cada prueba toma la de su rol; una igual a otra la reemplaza. Y cuando kbspec no logra crear o hacer correr una prueba —no llega a la pantalla, no encuentra el control—, propone grabar esa parte con el comando exacto, en vez de adivinar. La clave que se tipeó no queda en ningún lado.

3. El frontend manda — detectado, no adivinado

Un SPA con signals no se prueba como WebForms con postbacks. kbspec descubre el frontend por evidencia (la versión de Angular del package.json; .aspx = WebForms; .cshtml = MVC) y aplica las prácticas de ESE frontend:

Frontend	La regla que evita la suite intermitente
Angular 14	zone.js y rutas lazy: assert al contenido destino, nunca al spinner
Angular 21	zoneless: los asserts web-first son la única espera; con SSR, assert visible antes de interactuar
ASP.NET WebForms	Prohibido localizar por id (`ctl00_…` muta); el assert del resultado es la espera del postback
ASP.NET MVC	POST→redirect→GET: assert en la vista destino; `getByLabel` aprovecha `LabelFor`
React	`getByRole` primero; Next/SSR como Angular 21

kb pruebas doctor anuncia el frontend y sus prácticas completas viajan en el proyecto E2E (practicas/<frontend>.md, el AGENTS.md dice cuál); kb pruebas init deja el resumen escrito en la ficha. Agregar un frontend futuro = un archivo de prácticas + una regla de detección.

4. Qué se prueba — condiciones del 02, no requisitos

Pedir «una E2E por requisito» da exactamente eso: el camino feliz y nada más. kb pruebas condiciones abre cada requisito en lo que puede salir mal, con las técnicas de diseño de pruebas de siempre:

Del 02	Condiciones
cada `RF`	camino feliz · camino de falla · permiso denegado: el rol que según los Actores no puede, con su usuario de prueba
cada `RN` con ejemplo	sus valores límite (unitaria o API) · su ejemplo visto en pantalla
los datos que se registran	los obligatorios · cada validación

Cada condición trae su oráculo: el valor esperado, tal cual del 02. Nunca sale de lo que la pantalla muestra hoy, porque una prueba que copia el comportamiento actual también pasa cuando ese comportamiento está mal. El brief de pruebas trae una fila por condición, y kb pruebas revisar avisa de la que no tiene prueba, de la que solo afirma que «algo se ve» y de la que no afirma el texto que el 02 promete.

5. Explorar y escribir: el CLI de Playwright primero

Una E2E se escribe desde lo que la pantalla expone —roles y nombres reales de cada control—, no desde lo que uno supone. El agente trabaja por tres vías, en este orden:

El CLI de Playwright (incluido desde 1.59). Cada acción imprime el código TypeScript que va a la prueba: el localizador ya se ejecutó contra la app real. Y es el más barato: su skill cuesta ≈3.200 tokens y se lee una vez, contra ≈5.000–16.000 por turno de los esquemas del MCP (medido con Playwright 1.63). kb pruebas sesion abre la app pausada con el usuario, la credencial, el navegador y el proxy correctos, e imprime los comandos exactos.
El MCP de Playwright, solo si está habilitado. Registrado no es habilitado: en Copilot Business y Enterprise la política de la organización lo trae apagado, y eso no se ve desde la máquina. kbspec mira la política de VS Code, el settings.json, lo que el equipo declaró y si ya se usó; si no está confirmado, no lo usa.
kb pruebas explorar --pantalla "…", siempre disponible: corre con el Playwright de las pruebas, entra con el usuario del rol, navega con la receta y deja en el expediente cada control con su localizador sugerido.

kb pruebas ambiente dice cuál tenés, una vez por máquina.

6. El ambiente, sondeado una vez por máquina

Lo que hacía fallar las E2E antes de la primera línea —el navegador que no lanza, el Node que no le sirve a Playwright, el proxy que retiene cada página, el «acceso denegado»— no se le deja deducir al modelo en cada corrida: kb pruebas ambiente lo prueba una vez y lo deja escrito para esa máquina.

Node: el que pide el Playwright instalado sale de su paquete (1.63 pide 20+); una app Angular 14 corre en 16. Con Volta, las E2E corren con volta run --node <N> sin tocar el Node global.
Navegador: el primero que lanza de verdad —Edge, Chrome, Chromium—. Una política corporativa puede dejar uno instalado e incontrolable.
La app: qué contesta y qué ve el navegador. Un 401 de Windows, un 403, el proxy o un certificado no confiable se nombran con su remedio; si la app se alcanza sin el proxy, el perfil lo saltea (15-25 s menos por página en una red corporativa).

kb pruebas usa ese perfil y, si algo bloquea, no arranca: dice qué y cómo se arregla. El login se prueba aislado, con una captura por usuario: kb pruebas login --verificar. Y al terminar, kb pruebas dice cuánto tardó el login y cuáles fueron las pruebas más largas.

7. El generador oficial de Playwright, si el MCP está habilitado

Playwright trae tres agentes, y corren sobre el MCP. Si está habilitado, kb pruebas agentes usa el generador, que ejecuta cada paso contra la app y escribe la prueba desde lo que ejecutó, con el mismo plan que usa el CLI: un escenario por condición, arrancando con el usuario de esa condición y con el oráculo como resultado esperado. El planner no se usa porque deriva lo esperado de lo que la pantalla muestra; el healer tampoco, porque cambia valores esperados hasta que la prueba pasa. Lo que queda en rojo lo sana /kb-e2e-sanar: tres intentos, y el valor esperado del 02 no se toca.