Contratos y tests de datos

Objetivo

Definir qué significa “tabla sana” antes de que falle un dashboard.

Explicación

Un contrato útil combina esquema (columnas/tipos), integridad (PK/FK), dominio (valores permitidos), reglas de negocio y freshness. Los tests deben producir evidencia accionable. Un modelo analítico mal definido puede producir métricas correctas en apariencia pero equivocadas por duplicación o grain. Aquí practicarás cómo convertir reglas de negocio en estructuras y tests que puedan verificarse automáticamente. Para trabajar Contratos y tests de datos de forma profesional, no te quedes con el ejemplo: identifica la entrada, ejecuta el caso base, provoca al menos un caso incorrecto y compara el resultado con un control independiente. En este laboratorio el criterio de salida es concreto: Una lista explícita de reglas con dueño y acción ante fallo. La verificación principal será: Cada regla tiene una consulta/test que puede ejecutarse. Si no puedes explicar por qué pasa esa comprobación, vuelve al paso anterior antes de continuar.

Contexto profesional

Un modelo analítico mal definido puede producir métricas correctas en apariencia pero equivocadas por duplicación o grain. Aquí practicarás cómo convertir reglas de negocio en estructuras y tests que puedan verificarse automáticamente.

Ejemplo real

order_id: not_null + unique
customer_id: relationships -> dim_customers
amount: >= 0
status: accepted_values

Archivos o datos de entrada

• data/ecommerce_orders.csv

Práctica guiada

Escribe un contrato mínimo para orders.

Laboratorio paso a paso

• Prepara el entorno y localiza los datos/archivos de entrada: data/ecommerce_orders.csv. Antes de modificar nada, anota el número de filas, columnas u objetos que esperas usar.
• Reproduce el ejemplo real de la lección y guarda la salida. No avances hasta poder explicar qué hace cada bloque relacionado con «Contratos y tests de datos».
• Ejecuta la práctica guiada: Escribe un contrato mínimo para orders. Documenta el comando, consulta o acción exacta y el resultado obtenido.
• Resuelve el reto sin mirar la solución: Añade severidad: qué test bloquea producción y cuál sólo avisa. Si falla, registra el mensaje de error y formula una hipótesis antes de cambiar código.
• Compara tu resultado con el criterio esperado: Una lista explícita de reglas con dueño y acción ante fallo. Después ejecuta la comprobación: Cada regla tiene una consulta/test que puede ejecutarse.
• Provoca deliberadamente un caso problemático relacionado con este error frecuente: Testear cientos de columnas sin priorización genera ruido y fatiga.. Comprueba que sabes detectarlo y corregirlo.

Reto sin ayuda

Añade severidad: qué test bloquea producción y cuál sólo avisa.

Resultado esperado

Una lista explícita de reglas con dueño y acción ante fallo.

Cómo verificarlo

Cada regla tiene una consulta/test que puede ejecutarse.

Checklist de validación

• El resultado cumple: Una lista explícita de reglas con dueño y acción ante fallo.
• Has ejecutado esta verificación y puedes explicar el resultado: Cada regla tiene una consulta/test que puede ejecutarse.
• Has probado al menos un caso límite o dato inválido y el comportamiento es explícito, no silencioso.
• Puedes repetir la práctica desde cero sin copiar la solución y dejar evidencia (consulta, commit, captura o salida de consola).

Errores frecuentes

• Testear cientos de columnas sin priorización genera ruido y fatiga.

Qué debes recordar

La calidad es un contrato observable, no una revisión manual ocasional.

Preguntas de entrevista

• ¿Cuál es el grain y cómo lo demostrarías? Aplícalo concretamente a «Contratos y tests de datos».
• ¿Qué test detectaría el error más probable de este modelo? Explica qué evidencia enseñarías al revisor.

Siguiente paso

Conectarás calidad con CI/CD.