En esta página
Qué puede demostrar cada tipo de prueba
Una propiedad se verifica en el nivel que puede verla. Una prueba unitaria no puede ver un despliegue; una prueba de admisión no puede ver la respuesta de un modelo. La tabla indica, para cada nivel, qué demuestra, qué no puede demostrar y dónde lo usa el Companion.
| Nivel | Demuestra | No puede demostrar | Se usa para |
|---|---|---|---|
| Prueba unitaria | Un componente rechaza lo que tiene que rechazar | Que el componente esté en el camino | Esquemas de frontera, factorías de verificación, reglas de políticas |
| Prueba de arquitectura | El grafo de dependencias no tiene ninguna arista prohibida | Caminos de datos que no son importaciones | Frontera probabilística, aislamiento de normas |
| Prueba de contrato | Dos lados coinciden en una forma, incluida la procedencia obligatoria | Que ambos lados estén desplegados en versiones compatibles | Contratos de propuesta y de decisión |
| Prueba de integración | La propiedad se mantiene frente a la dependencia real | El comportamiento con otra configuración | Privilegios de la traza de auditoría, propagación de contexto, versiones de políticas |
| Prueba de extremo a extremo | Un estado prohibido no puede llegar a una salida | Caminos que la prueba no recorre | Valores no verificados, el fence de publicación |
| Prueba de despliegue o de admisión | La plataforma rechaza una carga de trabajo que incumple una regla | Nada de lo que hay dentro de la carga de trabajo | Imágenes fijadas, versiones nombradas, aislamiento de red |
| Evidencia manual | Una persona con nombre ejecutó un procedimiento escrito | Que vaya a volver a ejecutarse | Revisiones de licencias, repeticiones de decisiones históricas |
En ambas direcciones: el camino positivo y la prueba de dientes
Cada propiedad del Companion tiene una comprobación positiva (así se ve cuando pasa) y una negativa (este defecto, plantado, se rechaza). Una suite con solo la mitad positiva puede perder todas sus restricciones y seguir en verde. La mitad negativa es la que muestra que la comprobación está en el camino.
Los cinco pasos de una prueba de dientes están en la página Fences ejecutables, y el perfil de Python y FastAPI los ejecuta: una importación plantada rompe un contrato, una restricción borrada pone una prueba en rojo, un centinela plantado hace fallar el fence de publicación, y cada restauración se compara byte a byte.
Contar lo que se ejecutó
Un resultado no es “verde”. Es: qué comprobaciones se ejecutaron, cuántas aserciones se evaluaron, en qué ejecución identificada y con qué resultado. El modelo de informe de controles de COADF dice lo mismo de los controles: una comprobación omitida, un éxito anterior o una selección que no ejecutó ninguna prueba no son verificación vigente.
- Una selección de pruebas que no corresponde a nada puede tener éxito. Hay que afirmar el recuento.
- Una prueba que se omite por falta de base de datos no es una prueba superada. Hay que informar de ella como no ejecutada.
- Un job omitido puede notificarse como exitoso. Hay que exigir la comprobación que no puede omitirse.
Cuando el control es una persona
Algunos controles los sostiene una persona que ejecuta un procedimiento escrito: una revisión de licencias, una repetición de decisiones históricas muestreadas, una decisión en el merge. Hay que informar de ellos como manuales, con el nombre de la persona y el procedimiento, nunca como automatizados. Un control manual notificado con honestidad vale más que uno automatizado notificado sin rigor.
Lo que la verificación no establece
Las pruebas establecen que las pruebas pasaron. No establecen cumplimiento normativo, certificación ni evaluación de la conformidad, y una suite completa para cada propiedad de este Companion tampoco establece nada de eso. Los guardianes automatizados sobre texto y código son necesarios y no suficientes: no pueden ver un mecanismo expresado mediante flujo de control, identificadores renombrados o la geometría de un diagrama, y la revisión humana sigue formando parte de la verificación.