Saltar al contenido
Lakehouse LabLakehouse LabPreparación Databricks Data Engineer
Módulo 28 · Lección

assertDataFrameEqual y assertSchemaEqual

Contenido abierto

Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.

Lección 4 de 5

assertDataFrameEqual y assertSchemaEqual

Combina tests unitarios rápidos con integración Databricks para cubrir catálogos, permisos, formatos y comportamiento distribuido.

Duración
17 min aprox.
Objetivo
Combina tests unitarios rápidos con integración Databricks para cubrir catálogos, permisos, formatos y comportamiento distribuido.
Siguiente paso
Continuar con la siguiente lección
Ver detalles del módulo

Proyectos Python, dependencias y pruebas

Convierte notebooks en un paquete comprobable con límites claros y entornos reproducibles.

Al terminar podrás
  • Diseñar un paquete Python modular
  • Gestionar wheels y dependencias
  • Probar DataFrames y contratos
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Professional
Ruta relacionada
delivery
Dominios blueprint
Developing Code · Testing
Estado
Revisión editorial interna
Fuentes principales
Python unit testing in the workspace · What are workspace files?
Reportar un error
04
Diagnóstico

assertDataFrameEqual y assertSchemaEqual

Combina tests unitarios rápidos con integración Databricks para cubrir catálogos, permisos, formatos y comportamiento distribuido.

Mostrar prerrequisitos
Dificultad
Professional
Prerrequisitos
m12
Reportar un error en esta lección

Los tests unitarios verifican funciones y contratos con datos pequeños; no demuestran que el service principal pueda leer Unity Catalog, que la wheel se instale o que un `MERGE` sea idempotente. Las pruebas de integración despliegan en un catálogo aislado, ejecutan el entry point con identidad real y validan side effects. Deben usar nombres únicos por ejecución y limpiar sólo recursos etiquetados como temporales.

Databricks permite ejecutar pytest en el workspace y Databricks Connect puede acercar desarrollo local al compute remoto. Mantén la pirámide: muchas pruebas sin red, menos integraciones y pocas pruebas end-to-end. Marca suites y establece timeouts para que CI no ejecute por accidente una carga completa.

Modelo mental

Los tests unitarios y de integración responden preguntas distintas. Un unit test pregunta si una regla produce el resultado correcto con entradas controladas y sin depender de recursos externos. Una integración pregunta si el artefacto funciona con Spark, Unity Catalog, Delta, identidades, permisos, red y configuración reales. Simular todo en unit tests no demuestra que un GRANT exista; ejecutar todos los casos en un workspace hace feedback lento y caro. La pirámide adecuada concentra combinaciones y límites en tests rápidos, y reserva pocos recorridos representativos para fronteras de plataforma. Cada test posee datos y recursos aislados, limpia lo que crea y emite evidencia suficiente para distinguir fallo funcional de fallo ambiental.

Test unitario

Prueba rápida y aislada de una regla o componente con entradas controladas y dependencias externas sustituidas por contratos simples.

Permite explorar numerosos casos límite y localizar regresiones sin pagar despliegue ni variabilidad de plataforma.
Test de integración

Prueba que ejecuta el artefacto contra servicios reales relevantes para validar compatibilidad, permisos, formatos y comportamiento distribuido.

Detecta fallos que una simulación local no reproduce, especialmente en Unity Catalog, Delta, red e identidad.
Aislamiento por run

Uso de nombres, datos y recursos exclusivos para cada ejecución automatizada de la suite de integración.

Evita colisiones entre pipelines paralelos y permite limpiar con seguridad sólo los objetos creados por esa prueba.
PythonTest de integración idempotente
import pytest

@pytest.mark.integration
def test_merge_is_idempotent(spark, target_table, sample_orders):
    sample_orders.createOrReplaceTempView("incoming_orders")
    run_merge(spark, "incoming_orders", target_table)
    first = spark.table(target_table).count()

    run_merge(spark, "incoming_orders", target_table)
    second = spark.table(target_table).count()

    assert second == first

El fixture `target_table` debe crear un nombre aislado y eliminar sólo ese objeto al finalizar, incluso si el test falla.

Puntos clave

  • Unit tests cubren lógica; integración cubre plataforma, permisos y side effects.
  • Aísla catálogos/esquemas de prueba por ejecución.
  • Marca suites lentas y limita datos, tiempo y coste.

Evita

  • Ejecutar integraciones contra tablas compartidas y generar colisiones entre ramas.
  • Sustituir toda prueba por mocks y no detectar permisos o DDL incompatibles.

Recuerdo activo

¿Qué fallo sólo detectaría probablemente una prueba de integración?

Borrador privado · solo en este navegador
5 lecciones pendientes

Vista de lectura · sin ejecución

notebook-best-practices

notebook-best-practices · commit b4f55c1

notebooks/covid_eda_modular.py