Pruebas

La forma de la suite de pruebas refleja el producto: chequeos previos numerados, luego archivos por feature, más suites de regresión atadas a números de issue específicos, pruebas adversariales de “exploit” para vulnerabilidades pasadas y la suite MCP separada. Esta página mapea la cobertura.

Los archivos de pre-flight

• 00-compile.t: toda la aplicación compila (se omite limpiamente si Mojolicious/DBI no están instalados, ya que es un smoke check, no un instalador de dependencias).
• 01-schema.t: el schema en sí es lo que las migraciones luego reproducen; esta prueba valida el archivo de schema.
• 02-media-sniff.t: comportamiento del sniffing en la subida de media.
• 03-util.t, 04-webhook.t: suites unitarias de la capa de utilidades y del despacho de webhooks.

Suites por feature

Cada entidad gestionada por la API obtiene una suite propia, normalmente una por área: pages, posts, blocks (incl. helpers por tipo y la paleta de tipos de block), snippets, categories, media, documents, nav, redirects, themes, users, audit, drafts_restore, library, health, i18n, settings. Los formularios y los envíos también son un área propia (forms.t, submissions.t, submission_values.t), incluyendo las restricciones de subida de archivos y las pruebas de cuota.

Regresiones de seguridad y adversariales

Una familia dedicada exploit_… de pruebas recrea como tests los exploits reportados históricamente, cada uno con un comentario que describe la vulnerabilidad corregida:

• API keys de solo lectura que eluden las puertas de escritura (#4827): la puerta de sesión aceptaba API keys de alcance de lectura en rutas que mutan; la prueba fuerza a la puerta a exigir alcance de escritura para POST/PUT/PATCH/DELETE.
• Escalada de privilegios en la nav de la API: se rechaza mutar entradas de navegación (y el ingreso del log de 404 del admin) con una key de alcance insuficiente.
• Doble conteo del rate-limit de la API: el contador de rate por key debe incrementarse una vez por petición HTTP (una regresión antes lo contaba por cada capa de autenticación).
• Path traversal en documentos: nombres de archivo manipulados que intentan escapar del directorio de documentos.
• Mass-assignment en formularios: se rechaza enviar por POST valores para campos que el formulario nunca declaró.
• Inyección de dot-placeholder en archivos de theme: el manejo de rutas del editor de archivos de theme bloquea rutas manipuladas.
• Un barrido de regresión de seguridad (exploit_security_regression.t), una amplia suite adversarial.

La convención de nombres (exploit_issue_tag.t) hace que cada vulnerabilidad sea “testeable por regresión”: cada una está etiquetada con un número de issue específico para que los cambios futuros sepan qué corrección no deben romper.

Una suite completa para los comportamientos del subsistema de backup

Varios archivos separados cubren la maquinaria de backup y restore (backup_*.t): creación de snapshots, retención, previsualizaciones de dry-run del restore y confirmación, validación del manifest, retención, restores por API.

Suites de comportamiento del build

• Prueba mínima: los build_helpers ejecutan olas de render por idioma con el chequeo de microscopía Hunni (los builds de review-api).
• build_speed_4636/4637/4638: la serie de pruebas de rendimiento del build en paralelo; una suite de “timings” por build valida los tiempos por fase contra pruebas de fixtures; los builds incrementales se afirman en una prueba de modo mixto.
• Las suites de build miden sobre un corpus pequeño afirmando rutas de código (fingerprint, minificación, escaneos de enlaces, schema) y confirman condiciones de data races y de tiempo de pared (mediante los ejemplos de build_speed_4637: las ideas de regresión de velocidad múltiple).

Comportamientos de air-gap y de plataforma

• Comportamientos de email cuando air-gap está deshabilitado (admin_email_airgap.t), rutas de fallo de SMTP (admin_email_smtp.t, form_email_smtp_fail.t) y chequeos de CRLF forzados en SMTP hecho a mano (form_email_crlf.t).
• Puerta Turnstile: detrás de las settings turnstile_*, verifica los paneles como una suite separada (turnstile_gate.t).
• Ports de cara hacia arriba del enrutamiento de URL, escape XML (seguridad de sitemap/feed) y verificación de sentencias en los guards de sombra de rutas.

La miscelánea de suites que vale conocer

• La suite de migraciones verifica la unicidad de cada archivo de migración al re-ejecutarse en una DB temporal (idempotencia/re-ejecución segura) y contrasta migraciones contra el schema para que schema.sql y las migraciones no puedan divergir (migrations_lint.t, migrations_has_table.t, migrations_helpers.t).
• Las pruebas de instalación (installer-install.t, installer-bundle.t) cubren la ruta de instalación offline con bundle.
• zz_phase80_verify.t corre al final (último alfabéticamente) como capa de verificación que cruza múltiples áreas.

En esta sección

• Ejecutar la suite de pruebas
• Referencia del Test Helper