Este proyecto tiene 854 pruebas automáticas repartidas en 15 niveles distintos. Ninguno sobra: cada uno responde una pregunta que los demás no pueden responder. Esta página recorre todos, con los números reales del repositorio y las decisiones de ingeniería que hay detrás de cada uno.
Se puede leer en dos profundidades: los bloques de arriba dan el mapa completo en unos diez minutos; las secciones de decisiones y anatomía entran en el detalle.
Cifras de la última corrida en main, leídas de la tabla ci_runs que alimenta el propio pipeline. · ver el run en GitHub Actions
La forma de la pirámide no es decorativa: cada estrato está dibujado en proporción al número real de tests que tiene. Muchas pruebas baratas abajo, pocas y caras arriba. Cuando se invierte —muchos e2e y pocas unitarias— la suite se vuelve lenta, frágil y nadie la corre.
Un navegador real recorre el flujo completo. Caros, lentos, pocos.
La forma de la respuesta de la API queda congelada por un esquema Zod.
Base de datos real y desechable: transacciones, UNIQUE y concurrencia de verdad.
Lógica pura, sin BD ni red. Baratas: por eso son la mayoría.
Los otros 11 niveles no van en la pirámide, a propósito. SAST, accesibilidad, chaos, monitoreo, carga y usabilidad no verifican comportamiento: verifican propiedades del sistema (¿es seguro?, ¿es usable?, ¿aguanta?, ¿sigue vivo?). Meterlos en la pirámide daría a entender que son «más tests», y llevaría a compararlos por volumen cuando lo que importa de ellos es la cobertura de riesgo, no la cantidad.
Seis etapas, desde el portátil hasta las tres de la madrugada del día siguiente. Cada una es clicable: qué corre exactamente, cuánto tarda, qué la dispara y qué pasa si falla. Abajo se puede simular una corrida completa con tres desenlaces distintos — el tercero, el rollback automático, es el que mejor explica por qué la verificación no termina en el merge.
Si falla: No hay push. Es la única etapa donde el coste de un fallo es cero.
Si falla: —
Si falla: El job queda en rojo y el PR no se puede fusionar. Los scanners son la excepción: registran, no bloquean.
Si falla: El deploy anterior sigue sirviendo. Vercel no promueve un build que no compila.
Si falla: Rollback automático y push al teléfono. El job termina en rojo, pero el sitio ya volvió a estar sano.
Si falla: Se abre un incidente, se registra en el histórico y sale una alerta. Nada de esto depende de que yo esté mirando.
Elige un desenlace y mira cómo recorre el pipeline etapa por etapa.
El camino feliz: el código llega a producción y se queda.
Desenlace: La versión nueva se queda. Tiempo total desde el push: unos 10 minutos, sin intervención humana.
El caso más común. Nada llega a producción.
Desenlace: Coste del fallo: un job de CI de 4 minutos. Ningún usuario vio nada. Esto es exactamente para lo que existen los tests.
Pasa todos los tests y aun así rompe producción. El escenario que nadie enseña.
Desenlace: El sitio vuelve solo a la versión anterior en menos de un minuto, y me entero por el teléfono. Ningún test unitario podía haber detectado esto: la diferencia estaba en el entorno, no en el código.
Un test real del repositorio, disecado en capas. Es el patrón que siguen los 809: arrange (preparar), act (ejecutar), assert (afirmar). Conmuta las pestañas para ver qué líneas corresponden a cada capa.
// BD libsql en archivo temporal: las transacciones abren otra
// conexión y ':memory:' no comparte tablas entre ellas.
vi.mock('../src/db', async () => {
const file = join(tmpdir(), `payments-test-${process.pid}.db`)
const client = createClient({ url: `file:${file}` })
return { db: drizzle(client, { schema }), __client: client }
})
it('doble clic: requests concurrentes con la misma clave crean UN pago', async () => {
const key = `race-${crypto.randomUUID()}`
const [a, b] = await Promise.all([
createPaymentIdempotent(checkoutInput(key)),
createPaymentIdempotent(checkoutInput(key)),
])
expect(a.payment.id).toBe(b.payment.id)
})
Se sustituye el módulo de base de datos por uno que apunta a un archivo temporal único por proceso. Nunca se toca Turso: los tests escriben, y escribir en la base real gastaría cuota y contaminaría datos de clientes. El nombre lleva el PID para que dos corridas en paralelo no se pisen.
`Promise.all` con dos llamadas idénticas y la misma clave de idempotencia. No es una simulación de concurrencia: son dos operaciones realmente simultáneas contra la misma base, compitiendo por el mismo índice UNIQUE. Es la única forma de ejercer la condición de carrera de verdad.
Los dos resultados apuntan al mismo pago. Una sola línea, pero cubre todo lo que puede salir mal: si el UNIQUE no estuviera, si la captura del conflicto fallara, o si el segundo request devolviera un pago nuevo en vez del existente, este `expect` lo detecta.
Sin él, el bug no aparece en desarrollo (nadie hace doble clic probando) y aparece en producción con un cliente real cobrado dos veces. Es un fallo que se detecta tarde, cuesta dinero y erosiona la confianza. Cuatro líneas de test contra eso es la mejor relación coste/beneficio del repositorio.
Cada ficha trae la pregunta que responde el nivel y —más importante— su punto ciego. Ningún nivel es suficiente por sí solo; el conjunto funciona porque los puntos ciegos de uno los cubre otro. Filtra por cuándo corre o por si bloquea el deploy.
¿Esta función devuelve lo correcto para cada entrada, incluidas las raras?
Punto ciego: No sabe nada de la base de datos, la red ni el navegador. Una función puede ser perfecta y el sistema estar roto.
¿El UNIQUE, la transacción y la concurrencia se comportan como creo?
Punto ciego: Es SQLite local, no Turso remoto: no ve latencia de red ni límites de cuota.
¿La forma de la respuesta cambió sin que nadie se diera cuenta?
Punto ciego: Valida la forma, no el significado. Un campo puede tener el tipo correcto y el valor equivocado.
¿Un humano con un navegador puede completar el flujo de principio a fin?
Punto ciego: Lento y frágil por naturaleza. Por eso son 45 y no 450: cubren los flujos que perder duele, no cada botón.
¿Qué parte del código no ejecuta ni una sola prueba?
Punto ciego: Enorme: dice que la línea se ejecutó, no que se haya comprobado nada sobre ella. De ahí el nivel 6.
Si rompo esta línea a propósito, ¿algún test se entera?
Punto ciego: Carísimo en tiempo: son miles de ejecuciones de la suite. Por eso es semanal y nunca bloquea un PR.
¿Alguna librería que uso tiene una vulnerabilidad publicada?
Punto ciego: Solo ve lo que ya está publicado como advisory. Un 0-day no aparece.
¿Escribí yo algún patrón peligroso (inyección, XSS, secreto expuesto)?
Punto ciego: Análisis estático: no ejecuta nada. Genera falsos positivos y no ve fallos de lógica de negocio.
¿Puede usar esto alguien con lector de pantalla o sin ratón?
Punto ciego: Las herramientas automáticas detectan ~30-40% de los problemas de accesibilidad. El resto necesita a una persona.
Lo que acabo de desplegar, ¿está vivo de verdad?
Punto ciego: Comprueba que el sistema responde, no que responda bien. Un deploy puede estar «sano» y devolver datos incorrectos.
Cuando algo falle de verdad, ¿el sistema falla bien o se lleva todo por delante?
Punto ciego: Solo inyecta los fallos que se me ocurrieron. La realidad tiene más imaginación.
¿Sigue funcionando ahora mismo, a las 3 de la madrugada?
Punto ciego: Prueba desde fuera y sin sesión: no ve nada de lo que pasa detrás del login.
Funciona, pero ¿alguien que no lo construyó consigue usarlo?
Punto ciego: No se automatiza: hace falta gente real. Es el único nivel donde el resultado es una observación, no un booleano.
¿El sitio corriendo de verdad tiene una vulnerabilidad que el análisis estático no puede ver?
Punto ciego: Es un "baseline" pasivo: no intenta explotar nada, solo detecta cabeceras/config ausentes. Un DAST activo encontraría más, y también rompería más cosas.
¿Qué pasa con la latencia cuando entran 1000 personas a la vez?
Punto ciego: Nunca puede correr contra producción: Vercel factura por invocación y Turso tiene cuota. Va contra un preview desechable.
Esta es la parte que no sale en ningún tutorial. Cada decisión aquí abajo salió de algo que se rompió, se desincronizó o costó una tarde de depuración. El formato es siempre el mismo: síntoma → causa → decisión → dónde vive.
Síntoma
Los tests de concurrencia fallaban con «no such table», pero solo los que abrían una transacción.
Causa
Una transacción de libSQL abre otra conexión, y una base en memoria no comparte tablas entre conexiones.
Decisión
Toda base de prueba es un archivo en el directorio temporal del sistema, con nombre único por PID y timestamp.
tests/payments.test.ts, tests/cobros-db.test.ts
Síntoma
Un test pasaba en verde contra un esquema que ya no existía en producción.
Causa
El CREATE TABLE estaba escrito a mano en el test y se desincronizó cuando otro trabajo añadió columnas.
Decisión
Los tests nuevos migran con `drizzle-orm/libsql/migrator` apuntando a la carpeta drizzle/ real. Mismo esquema que producción, por construcción.
tests/contracts.test.ts
Síntoma
El servidor de e2e arrancaba contra una base que no existía.
Causa
Playwright levanta el webServer ANTES de ejecutar globalSetup. Sembrar allí llega tarde.
Decisión
La siembra es parte del propio comando del webServer: `node scripts/seed-e2e.mjs && npm run dev`.
playwright.config.ts
Síntoma
El build de producción no se podía servir localmente para probarlo.
Causa
El adaptador de Vercel no soporta `astro preview`; haría falta `vercel dev`.
Decisión
Los e2e corren contra `astro dev`. El middleware —que es justo lo que verifican— se comporta igual en dev.
playwright.config.ts
Síntoma
Necesitaba demostrar, no afirmar, que la demo pública jamás muestra datos reales.
Causa
La demo usa una base Turso distinta seleccionada por AsyncLocalStorage. Un error de contexto filtraría datos de clientes.
Decisión
La base «principal» de e2e se siembra con el prefijo `CENTINELA-REAL `. Un test afirma que ese texto no aparece nunca en la demo. Si el aislamiento se rompe, el test lo grita.
e2e/demo.spec.ts, playwright.config.ts
Síntoma
Un módulo importado desde el navegador reventaba al arrastrar `node:crypto` y la conexión a BD.
Causa
Las páginas .astro con <script> ejecutan ese código en el cliente, donde no existe Node.
Decisión
Se separó en un módulo puro isomorfo y otro solo-servidor: cobros.ts / cobros-crypto.ts, payments-state.ts / payments.ts. Como efecto secundario, la lógica pura quedó trivial de testear.
src/lib/payments-state.ts, src/lib/cobros.ts
Síntoma
Un porcentaje de cobertura, sea alto o bajo, no me decía si los tests comprobaban algo.
Causa
La cobertura mide ejecución, no verificación. Un test sin un solo `expect` cubre líneas igual.
Decisión
Stryker muta el código y vuelve a correr la suite contra cada mutante. Si un mutante sobrevive, hay una línea que ningún test defiende.
stryker.config.json, src/lib/lab/mutation.ts
Síntoma
Un pipeline que tarda 40 minutos es un pipeline que la gente evita.
Causa
Mutar cada línea y re-ejecutar la suite contra cada mutante son miles de ejecuciones. Es lento por diseño, no por estar mal configurado.
Decisión
Job aparte: `workflow_dispatch` o domingos a las 08:00 UTC. Nunca bloquea un PR.
.github/workflows/mutation.yml
Síntoma
Un advisory nuevo sobre una dependencia transitiva tumbaría el pipeline sin que yo pueda arreglarlo.
Causa
npm audit, CodeQL y axe reportan cosas que a veces no dependen de mi código.
Decisión
`continue-on-error: true` en los tres. Los hallazgos se deduplican por fingerprint, persisten entre corridas y el semáforo real vive en el panel LAB.
.github/workflows/security.yml, a11y.yml
Síntoma
Un fork o un repo recién clonado no tiene mis tokens y el pipeline entero fallaría.
Causa
VERCEL_TOKEN, LAB_INGEST_TOKEN y NTFY_TOPIC son míos, no del proyecto.
Decisión
Cada paso comprueba si el secret existe y, si no, emite un ::warning:: y sigue. Sin token no hay rollback ni reporte, pero el pipeline no se rompe. Es el mismo principio fail-open del middleware.
.github/workflows/ci.yml
Síntoma
Un deploy verde en CI puede estar roto en producción por una variable de entorno que solo existe en local.
Causa
CI prueba el código; producción ejecuta el código *más* su entorno. Son dos cosas distintas.
Decisión
Tras el deploy, el pipeline espera a ver su propio SHA en /api/health, hace 3 health checks y revierte solo si no pasan 2. La verificación no termina en el merge.
job verify-production de ci.yml
Síntoma
Sabía qué pasaba cuando todo funcionaba; no tenía ni idea de qué pasaba cuando la BD tardaba 5 segundos.
Causa
Ningún test convencional prueba el comportamiento degradado.
Decisión
Flags de caos en BD que el middleware aplica a rutas concretas: latencia o error 500, con TTL acotado y una lista de rutas que jamás se pueden romper. Y 12 tests que prueban al propio motor de caos.
src/lib/chaos.ts, tests/chaos.test.ts
Es la distinción más útil de toda esta página y la que casi nadie hace. La cobertura mide qué líneas se ejecutaron; el mutation score mide qué líneas están defendidas. No son lo mismo, y confundirlas produce suites que dan un 90% de cobertura sin comprobar nada.
it('formatea el monto', () => {
formatCOP(1500000) // se ejecuta…
}) // …pero no afirma NADALa línea de formatCOP aparece como cubierta. El reporte de cobertura está en verde. Y sin embargo, la función podría devolver cualquier cosa.
// Stryker cambia el separador…
- return `$ ${miles} COP`
+ return `${miles}`
// …vuelve a correr la suite: SIGUE VERDE
// → mutante SURVIVEDUn mutante que sobrevive es la prueba de que esa línea no tiene a nadie vigilándola. Es exactamente el caso que encontró Stryker en money.ts: cinco literales de cadena sin un solo test que comprobara la etiqueta.
Se mutó la línea y algún test falló. Bien: esa línea está defendida.
Se mutó la línea y toda la suite siguió en verde. Hay un agujero.
Ningún test ejecuta siquiera esa línea. Ni se intentó matar al mutante.
La mutación provocó un bucle infinito. Cuenta como detectada.
Y sí, 59.8% de cobertura no es una cifra de la que presumir.Se mide sobre src/lib/** entero — 2.164 líneas — incluyendo módulos que solo se ejecutan contra servicios externos (pasarela real, notificaciones, RDAP) y que no se prueban con tests unitarios sino en el LAB y en producción. Inflarla sería trivial: bastaría con excluir esos archivos del cálculo. Se deja el número completo porque un porcentaje maquillado no informa de nada, y porque el dato que de verdad importa —si las líneas que sí se prueban están defendidas— lo da el mutation score, no este.
Por qué esto no corre en cada push: Stryker genera un mutante por cada operador, literal y condición de src/lib/**, y vuelve a ejecutar la suite entera contra cada uno. Son miles de ejecuciones. Un pipeline de cuarenta minutos es un pipeline que la gente aprende a saltarse, así que la mutación vive en su propio job semanal (mutation.yml, domingos 08:00 UTC) y nunca bloquea un PR.
Ninguna suite de pruebas está terminada, y una que se presenta como completa está mintiendo o no se ha mirado con suficiente atención. Estos son los huecos conocidos de esta, con el motivo por el que siguen abiertos.
Fase 5 del plan del LAB. Los scripts y la tabla están diseñados; falta el VERCEL_TOKEN que permite crear el preview desechable contra el que se dispara la carga. Nunca irá contra producción: Vercel factura por invocación y Turso tiene cuota de filas.
La metodología de 6 pasos está documentada y aplicada a un flujo real, pero la columna «Evidencia» sigue vacía: falta ejecutar la prueba con participantes de verdad. Un guion sin participantes no es una prueba de usabilidad.
No hay comparación de capturas entre versiones. Un cambio de CSS que rompa el layout en móvil pasaría los 543 tests sin despeinarse. Es el hueco más grande que tiene hoy la suite.
Se recogen Web Vitals reales de visitantes (RUM), pero nada falla si una página empeora. Falta un presupuesto de rendimiento que bloquee un PR que degrade el LCP.
Hallazgos abiertos ahora mismo: 32 sin resolver reportados por los escáneres automáticos, de los cuales 25 son de severidad alta o crítica. Son hallazgos reales, no una demo: se deduplican por huella y conservan su estado entre corridas. El detalle vive en el panel privado; aquí solo el agregado.
Todo lo de esta página se puede reproducir clonando el repositorio. Requiere Node ≥ 22.12 — con Node 20 el build de Astro se rompe. Ningún comando de aquí necesita credenciales: las bases de prueba son archivos desechables.
npm testLos 799 tests de Vitest. ~4 segundos.npm run test:watchModo interactivo: re-ejecuta solo lo que toca el archivo que estás editando.npm run test:coverageGenera el reporte HTML en coverage/ para ver qué líneas no toca nadie.npm run test:e2ePlaywright. Siembra dos bases desechables y levanta el servidor solo.npm run test:e2e:uiEl inspector de Playwright: ver el navegador paso a paso y depurar un test.npm run test:contractsSolo los contratos de API, contra una BD migrada con el migrador real.npm run test:mutationStryker sobre src/lib. Tarda mucho, avisado quedas.npx astro checkType-check completo. No es un test, pero atrapa lo mismo que muchos.Por qué 45 tests e2e y no 450, y cómo se eligen los flujos que sí merecen uno.
Mutation testing en la práctica: qué mutantes sobrevivieron y qué dijeron de mi suite.
SAST y accesibilidad con hallazgos reales, deduplicados y con ciclo de vida propio.
Inyectar fallos en producción con TTL acotado y rutas que nunca se pueden romper.
¿Cambiar a inglés?
Tu navegador está en inglés. Puedo mostrarte el sitio en ese idioma.