Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLección 4 de 5
EXPECT OR FAIL
Un contrato de calidad define dimensión, expresión, acción, umbral, owner y procedimiento de remediación antes de escribir código.
17 min aprox.
04DiagnósticoEXPECT OR FAIL
Un contrato de calidad define dimensión, expresión, acción, umbral, owner y procedimiento de remediación antes de escribir código.
+
EXPECT OR FAIL
Un contrato de calidad define dimensión, expresión, acción, umbral, owner y procedimiento de remediación antes de escribir código.
Validez, completitud, unicidad, consistencia, puntualidad y exactitud requieren evidencias diferentes. `amount >= 0` comprueba validez, pero no exactitud frente al sistema de pagos. Una expectation fila a fila tampoco demuestra unicidad global sin una transformación o agregación adecuada.
Las reglas evolucionan como código versionado. Un cambio de umbral debe revisar impacto histórico y despliegue; renombrar una expectation rompe series de métricas. Las reglas críticas pueden agruparse con `expect_all_or_fail`, mientras reglas de observación usan `expect_all` para una configuración compartida.
structural_rules = {
"order_id_present": "order_id IS NOT NULL",
"event_ts_present": "event_ts IS NOT NULL",
"amount_non_negative": "amount >= 0",
}
business_observations = {
"known_currency": "currency IN ('EUR', 'USD', 'GBP')",
"reasonable_amount": "amount <= 100000",
}Agrupar expresiones facilita reutilización, pero documenta por separado la acción y el owner de cada conjunto.
¿Puede `amount >= 0` demostrar que el importe cobrado es exacto?
Profundiza
Un contrato de calidad conecta significado de negocio con una expresión ejecutable y una respuesta operativa. Por cada regla documenta dimensión —validez, completitud, unicidad, consistencia, puntualidad—, ámbito, expresión, tolerancia, acción, owner, evidencia y procedimiento de remediación. Una expectation solo implementa la parte por fila; una clave única global, reconciliación entre tablas o frescura requieren controles agregados adicionales. Los umbrales deben basarse en riesgo: cero puede ser correcto para identidad primaria, pero absurdo para un atributo opcional con fuente imperfecta. Versionar el contrato permite explicar por qué cambió una tasa y revalidar historia. Antes de escribir código se prueban ejemplos límite, nulls, zonas horarias y evolución de schema. Separar regla de acción posibilita observar primero una nueva constraint, calibrarla y endurecerla sin modificar su significado.
Categoría semántica que describe qué propiedad se evalúa, como completitud, validez, consistencia, unicidad o puntualidad del dato.
Evita listas inconexas de expresiones y ayuda a comprobar que el producto cubre riesgos relevantes.Población exacta sobre la que se calcula una tasa de cumplimiento, con inclusiones, exclusiones y ventana temporal definidas.
Impide métricas engañosas cuyo porcentaje cambia por mezclar datos de prueba, replays o segmentos no comparables.Especificación identificable de reglas, umbrales, acciones y ownership válida para una versión del producto de datos.
Permite auditar cambios, ejecutar reglas en sombra y atribuir variaciones a datos o a definiciones.Resumen
Puntos clave
- Cada expresión debe medir la dimensión que afirma medir.
- Acción y umbral forman parte del contrato, no son detalles de implementación.
- Nombres estables permiten comparar calidad entre versiones y actualizaciones.
Evita
- Llamar 'exactitud' a una comprobación de formato que no compara con una fuente autoritativa.
- Cambiar nombres de reglas en cada release y perder continuidad del indicador.