Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLecció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.
17 min aprox.
04DiagnósticoassertDataFrameEqual y assertSchemaEqual
Combina tests unitarios rápidos con integración Databricks para cubrir catálogos, permisos, formatos y comportamiento distribuido.
+
assertDataFrameEqual y assertSchemaEqual
Combina tests unitarios rápidos con integración Databricks para cubrir catálogos, permisos, formatos y comportamiento distribuido.
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.
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 == firstEl fixture `target_table` debe crear un nombre aislado y eliminar sólo ese objeto al finalizar, incluso si el test falla.
¿Qué fallo sólo detectaría probablemente una prueba de integración?
Profundiza
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.
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.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.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.Resumen
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.