wesleymatosdev/proof-bearing-verification

Verificación con Prueba de Comportamiento

Úsalo al revisar una implementación existente, trabajo delegado o preparación para entrega. Una verificación en verde, una revisión estática o un resumen de agente no son prueba a menos que ejerciten el comportamiento afirmado.

Cuándo Usarlo

• Un agente dice que una tarea está completa.
• Las pruebas pasan pero se desconoce su fuerza conductual.
• Una corrección de error, cambio de interfaz, integración o cambio operativo necesita validación.
• Una revisión estática entra en conflicto con un comportamiento previamente verificado en tiempo de ejecución.

No lo uses en lugar de test-driven-development para código nuevo; úsalo para validar la evidencia después o junto a la implementación.

Procedimiento

1. Nombra el comportamiento afirmado.

   • Indica el resultado visible para el usuario u observable externamente que se está afirmando.
   • Finalización: la afirmación se puede probar sin referirse a detalles de implementación.

2. Elige el punto de integración real más cercano.

   • Prefiere una interacción de componente montado, solicitud de integración, invocación de CLI, llamada API o flujo de extremo a extremo en lugar de una prueba de solo importación o solo instantánea.
   • Usa cargas útiles realistas y fixtures con forma de producción.
   • Finalización: la sonda alcanza la ruta de código cuyo comportamiento se afirma.

3. Prueba que la sonda tenga dientes.

   • Para comportamiento cambiado o eliminado, primero observa un fallo sin la implementación o con un no-op deliberado cuando sea seguro.
   • Una prueba que permanece verde cuando la unidad modificada se omite es vacua y no debe usarse como evidencia.
   • Finalización: la sonda puede distinguir el comportamiento funcional del comportamiento roto relevante.

4. Ejecuta e inspecciona la prueba.

   • Ejecuta la verificación enfocada, luego las verificaciones más amplias aplicables del proyecto.
   • Lee la prueba o el arnés en lugar de confiar en un resumen de su autor.
   • Finalización: la salida y la implementación respaldan la afirmación exacta.

5. Maneja evidencia contradictoria.

   • Trata el comportamiento en tiempo de ejecución verificado por el usuario como evidencia que requiere explicación antes de reemplazarlo con una recomendación de revisión estática.
   • Rastrea el framework, caché, infraestructura o semántica de tiempo de ejecución que causa la aparente contradicción.
   • Finalización: cualquier cambio sigue la evidencia más sólida disponible, no la confianza del revisor.

Errores Comunes

• No verifiques el comportamiento de la consola del navegador con Node. El console.log de Node no soporta %c — trata las cadenas de estilo como argumentos planos y las descarta silenciosamente, por lo que un arnés de Node/Python imprime una cuadrícula limpia y enmascara una representación de DevTools rota. Para verificar la salida de consola, controla el navegador real a través de CDP (Chrome sin cabeza --remote-debugging-port + un script WebSocket que capture Runtime.consoleAPICalled), u obtén evidencia visible para el usuario de la consola real. Un arnés que se ejecuta en un motor de consola diferente no es prueba.
• Un console.log con muchos segmentos %c desborda DevTools. El formateador de consola consume argumentos un especificador a la vez; cuando una sola llamada tiene demasiados segmentos con estilo (por ejemplo, ~193), las cadenas de estilo de cola no se consumen como estilos — se imprimen literalmente como texto sin formato (el clásico volcado de basura color:#...;font-family...). Remedio según la documentación de Chrome: un console.log por línea/fila, cada uno con un número limitado de runs %c. Por eso el arte ASCII por carácter como un gigante console.log('%c%s%c%s...') filtra estilos.
• “Se renderiza sin lanzar,” fixtures de solo tipo, mocks que reemplazan la unidad bajo prueba y pruebas .todo() no prueban comportamiento.
• Nunca cambies el comportamiento de producción solo para satisfacer un andamiaje de prueba superficial.
• No afirmes finalización cuando una dependencia externa, interacción de interfaz o ruta de despliegue no fue ejercitada; informa el límite no verificado.

Verificación

Un informe de finalización debe incluir: el comportamiento probado, el comando o acción exacta utilizada, el resultado observado y cualquier límite que permanezca sin verificar.