El marco de fixtures

Qué es un fixture de referencia

Un fixture de referencia es un estado sintético de tenant, construido a mano para representar una situación que la comprobación debe reconocer, pasado por la función real de la comprobación y verificado contra un veredicto concreto. No es un mock de la comprobación. Es entrada real a la lógica de detección real, con la respuesta escrita de antemano.

Como el fixture ejecuta la función real, prueba lo que se distribuye: la misma ruta de código que sigue un escaneo real, menos la llamada de red que recogió los datos. Si la lógica de veredicto está mal, el fixture falla. Si alguien cambia después la lógica y rompe un caso, el fixture que cubría ese caso se pone en rojo antes de que el cambio pueda integrarse.

Las tres aserciones

Cada comprobación que puede probarse con fixtures se somete a tres casos. Juntos demuestran que la comprobación acierta cuando todo está bien, acierta cuando no lo está, y es honesta cuando no puede saberlo.

La puerta

Cuatro puertas se ejecutan antes de cada versión: los fixtures de referencia (lógica de veredicto), los contratos de consulta de los colectores (cada colector solicita exactamente los endpoints y parámetros de API que su comprobación lee), la prueba de esquema de Zero Trust (cada comprobación declara pilar y peso) y la suite completa de pruebas unitarias. Una ejecución en rojo en cualquiera de ellas bloquea la versión.

La ejecución de fixtures también emite los números de arriba como un artefacto legible por máquina. Este sitio web lee ese artefacto, y su propia compilación falla si un recuento de páginas o una estadística no coincide con él. Por eso los recuentos de aquí no pueden desviarse: lo único que puede cambiarlos es una ejecución que pasó.

Las puertas demuestran que pueden fallar

Una luz verde solo significa algo si el rojo es alcanzable. Cada puerta de la versión tiene una autoprueba de veneno: se inyecta un fallo deliberado a través de la forma literal de invocación de la puerta, y la puerta debe salir con código distinto de cero. Una puerta que sigue en verde con entrada envenenada hace fallar la versión.

Este sitio web se aplica la misma regla. Sus guardas de compilación (recuentos de páginas, números derivados, escaneos de competidores y términos retirados, ratios de contraste) tienen cada una un caso de veneno que se ejecuta en CI con cada cambio: una definición sin página, un artefacto de ejecución en rojo, una estadística escrita a mano, un par de colores que no cumple. Cualquier guarda que no pueda fallar pone la compilación en rojo.

Del módulo a la página, de extremo a extremo

La tubería completa detrás de cada número de este sitio, en texto:

1. Las definiciones de comprobaciones y los fixtures de referencia del módulo viven en el repositorio de Guerrilla.
2. La ejecución de pruebas que valida la versión pasa cada fixture por las funciones reales. Solo una ejecución en verde emite el artefacto (recuentos, veredictos por comprobación, versión del módulo, SHA de git).
3. El generador del sitio lee el artefacto y las definiciones y emite una página de datos por comprobación, más los índices de categorías y la tabla cruzada de líneas base. Se niega a ejecutarse con un artefacto en rojo u obsoleto.
4. La compilación del sitio genera esas páginas y vuelve a verificarlo todo: el recuento de páginas es igual a las comprobaciones probadas, sin números no derivados, sin nombres de competidores, sin nombres en clave retirados, ambos temas pasan el contraste.
5. CI ejecuta la compilación, las autopruebas de veneno de las guardas y las comprobaciones de accesibilidad en cada cambio. No existe una ruta de despliegue que las omita.

Escribe un fixture, paso a paso

Aquí hay uno real del repositorio. GROUP-001 comprueba si los grupos de Google Workspace están restringidos a usuarios del dominio. Lee un ajuste de política de Cloud Identity, groups_for_business.groups_sharing. Un fixture es un archivo JSON que nombra la comprobación, el escenario, el veredicto esperado y el auditData sintético que la comprobación verá. Déjalo en Tests/Fixtures/ y se recoge automáticamente.

1. Limpio, se espera PASS

El uso compartido está limitado a usuarios del dominio, el estado recomendado. La comprobación debe pasar.

{
  "checkId": "GROUP-001",
  "scenario": "clean",
  "expectedStatus": "PASS",
  "auditData": { "CloudIdentityPolicies": { "ByType": {
    "groups_for_business.groups_sharing": [
      { "setting": { "value": { "collaborationCapability": "DOMAIN_USERS_ONLY" } } } ] } } }
}

2. Malo conocido, se espera FAIL

Un campo cambia a ANYONE_CAN_ACCESS, la exposición que la comprobación existe para atrapar. Nada más cambia. La comprobación debe fallar.

{
  "checkId": "GROUP-001",
  "scenario": "known-bad",
  "expectedStatus": "FAIL",
  "auditData": { "CloudIdentityPolicies": { "ByType": {
    "groups_for_business.groups_sharing": [
      { "setting": { "value": { "collaborationCapability": "ANYONE_CAN_ACCESS" } } } ] } } }
}

3. No recolectable, se espera No evaluado

La API de políticas devolvió un 403, así que el ajuste es desconocido. La comprobación debe informar No evaluado, no adivinar. SKIP es como un fixture escribe No evaluado.

{
  "checkId": "GROUP-001",
  "scenario": "not-assessed",
  "expectedStatus": "SKIP",
  "auditData": { "Errors": { "CloudIdentityPolicies": "Policy API 403" } }
}

Ese es todo el contrato. Tres archivos pequeños, cada uno una forma real de tenant con la respuesta escrita. Ejecuta pwsh Tests/Invoke-FixtureTests.ps1 y la suite pasa tus fixtures por la comprobación y confirma cada veredicto. Cuando pasan, la comprobación está probada, y un mantenedor puede aceptártela sin tener tu tenant delante.

Contribuir

El requisito de fixtures es lo que permite a este proyecto aceptar una comprobación de un desconocido. Si has encontrado un veredicto equivocado, o una comprobación que merece añadirse, o una forma real e inusual de tenant que merece capturarse como fixture, eso es una contribución y se acredita. La escalera de contribución.