Comprobar lo que llegó al usuario

El repartidor marcó «entregado». La bolsa llegó, pero contenía otro pedido. Una señal de finalización puede describir una parte del recorrido sin demostrar que la persona recibió lo esperado.

En una aplicación sucede algo similar: responder una consulta de estado no demuestra que estén funcionando sus reglas. La verificación posterior debe relacionar la versión activa con un comportamiento importante para el usuario.

Disponible, identificada y correcta

Esta respuesta ficticia indica que la aplicación contesta y declara una versión:

{"estado": "ok", "version": "demo-1"}

Ahora observemos el pedido de referencia: tres unidades de S/ 25.00, más S/ 5.00 de envío. Los importes están en céntimos:

{"subtotal": 7500, "envio": 500, "total": 8000}

La primera respuesta informa disponibilidad e identidad declarada. La segunda permite contrastar una regla. Para comprobar el límite, también necesitamos un subtotal de 10000 con envío cero. Una sola compra correcta no demuestra todos los casos.

Elegir señales que permitan actuar

Además de los ejemplos, en una operación real se observa si aumentan los errores, cambian los tiempos de respuesta o aparecen fallos en recorridos críticos. Cada señal necesita contexto: qué mide, cuál era el comportamiento anterior y cuándo corresponde investigar.

Un promedio puede esconder solicitudes muy lentas. Una ausencia de errores registrados puede significar que faltan registros. Por eso las señales se interpretan junto con el funcionamiento de los instrumentos que las producen.

Las comprobaciones sobre producción deben evitar efectos no deseados. Una consulta de prueba no debería crear pedidos reales, enviar mensajes o cobrar. Si hace falta una operación con efectos, se define expresamente cómo controlarla y reconocerla.