Práctica: Añadir Tests a un Modelo de Clientes

Concepto clave

En el modelado de datos con dbt Cloud, los tests son verificaciones automatizadas que garantizan la calidad y consistencia de tus datos transformados. Piensa en ellos como los controles de calidad en una línea de producción: cada modelo debe pasar ciertos chequeos antes de considerarse listo para consumo. A diferencia de validaciones manuales, los tests en dbt se ejecutan automáticamente con cada ejecución, detectando problemas como valores nulos inesperados, duplicados o relaciones rotas entre tablas.

Existen dos tipos principales de tests en dbt: tests genéricos (como not_null, unique, accepted_values) que vienen predefinidos, y tests personalizados que tú defines según reglas de negocio específicas. Por ejemplo, en un modelo de clientes, podrías testear que el campo email siempre tenga un formato válido o que la fecha de registro no sea futura. La clave está en que estos tests no solo evitan errores, sino que documentan implícitamente las expectativas sobre tus datos.

Cómo funciona en la práctica

Imagina que estás construyendo un modelo llamado customers en tu warehouse. Primero, defines el modelo en SQL dentro de dbt Cloud. Luego, en un archivo YAML asociado, especificas qué columnas deben ser testeadas y con qué criterios. dbt Cloud ejecutará estos tests después de cada dbt run, mostrando resultados en la interfaz. Si un test falla, el proceso se detiene (o genera advertencias, según configuración), permitiéndote corregir antes de propagar datos incorrectos.

Paso a paso: 1) Identifica las columnas críticas en tu modelo (ej: customer_id, email). 2) Decide qué tests aplicar (ej: unique para ID, not_null para email). 3) Añade la configuración en el archivo YAML del modelo. 4) Ejecuta dbt test en dbt Cloud para validar. 5) Revisa los logs y corrige cualquier fallo. Este flujo se integra fácilmente en pipelines CI/CD, asegurando calidad continua.

Codigo en accion

Antes de añadir tests, tu modelo customers podría verse así en SQL:

-- models/customers.sql
SELECT 
    customer_id,
    email,
    signup_date,
    country,
    total_orders
FROM raw_customers
WHERE is_active = true

Y el archivo de configuración YAML asociado, después de añadir tests, sería:

# models/schema.yml
version: 2

models:
  - name: customers
    columns:
      - name: customer_id
        tests:
          - unique
          - not_null
      - name: email
        tests:
          - not_null
          - relationships:
              to: ref('valid_emails')
              field: email_address
      - name: signup_date
        tests:
          - not_null
          - accepted_values:
              values: ['2020-01-01', '2021-01-01', '2022-01-01']
      - name: country
        tests:
          - not_null
      - name: total_orders
        tests:
          - not_null
          - dbt_expectations.expect_column_values_to_be_between:
              min_value: 0
              max_value: 1000

Errores comunes

• Testear todas las columnas innecesariamente: Añadir tests a columnas no críticas ralentiza la ejecución y genera ruido. Enfócate en columnas clave como IDs, fechas y métricas de negocio.
• Ignorar tests de relaciones: No verificar que las claves foráneas (ej: customer_id en órdenes) apunten a registros existentes puede llevar a datos huérfanos y reportes incorrectos.
• Usar valores hardcodeados en tests: En tests como accepted_values, evita listas fijas que pronto quedarán obsoletas; en su lugar, referencia tablas de configuración o usa tests personalizados dinámicos.
• No priorizar tests por criticidad: dbt permite marcar tests como severity: error o warn. No diferenciarlos puede hacer que fallos graves pasen desapercibidos.
• Olvidar actualizar tests al cambiar modelos: Si modificas una columna (ej: renombrar signup_date a registration_date

Checklist de dominio

1. He identificado al menos 3 columnas críticas en mi modelo de clientes para testear (ej: ID, email, fecha).
2. Sé configurar tests genéricos (unique, not_null) en un archivo YAML de dbt.
3. Puedo crear un test personalizado simple (ej: verificar que total_orders no sea negativo).
4. He ejecutado dbt test en dbt Cloud y interpretado los resultados exitosos/fallidos.
5. Entiendo cómo usar tests de relaciones (relationships) para mantener integridad referencial.
6. Puedo integrar tests en un pipeline básico (ej: ejecutar tras cada dbt run en desarrollo).
7. Sé dónde documentar expectativas de negocio usando tests (ej: en comentarios YAML o con tags).