prueba

Uso

test::: [datos_ Búsquedas]::

Jerarquía Archivo del modelo test - o - Ver archivo test - o - Archivo de prueba de datos test

Valor predeterminado Ninguna Acepta Es el identificador de la prueba de datos, más los subparámetros que definen las aserciones y las consultas de prueba.

Definición

Consulte el tema Pruebas de datos de LookML: Recomendaciones y prácticas recomendadas para obtener más información y sugerencias sobre las pruebas de datos.

Looker tiene el validador de LookML a fin de verificar que su código de LookML sea válido sintácticamente y el validador de contenido para verificar las referencias de objetos entre su contenido y su modelo.

Además de esos validadores, el parámetro test te permite validar la lógica de tu modelo. Para cada prueba de datos, creas una consulta y una sentencia de aserción yesno. La prueba de datos ejecuta la consulta de prueba y verifica que la aserción sea verdadera para cada fila de la consulta de prueba. Si la declaración de aserción muestra yes para cada fila de la consulta de prueba, se pasa la prueba de datos.

Si la configuración de tu proyecto está establecida para exigir la realización de pruebas de datos antes de la implementación en la producción, el IDE presentará el botón Ejecutar pruebas después de confirmar los cambios en el proyecto. Los desarrolladores de LookML deben ejecutar las pruebas de datos antes de implementar cambios en la producción.

Independientemente de si tu proyecto requiere pruebas de datos antes de la implementación en producción, un desarrollador de LookML que se encuentra en el modo de desarrollo puede ejecutar pruebas de datos en cualquier momento para verificar la lógica del modelo.

Puedes crear pruebas de datos en archivos de modelo, ver archivos o en archivos de prueba de datos independientes y dedicados. Cuando uses un archivo exclusivo para alojar las pruebas de datos, recuerda include el archivo de prueba en cualquier archivo de modelo o archivo de vista en el que quieras ejecutar las pruebas.

Una prueba de datos no puede tener el mismo nombre y explore_source que otra prueba de datos en el mismo proyecto. Si usas el mismo explore_source para varias pruebas de datos en tu proyecto, asegúrate de que los nombres de las pruebas de datos sean únicos.

El parámetro test tiene los siguientes subparámetros:

• explore_source: Define la consulta que se usará en la prueba de datos.
• assert: Define una expresión de Looker que se ejecuta en cada fila de la consulta de prueba para verificar los datos.

Una vez que definas el LookML para tu prueba, puedes ejecutar la prueba de datos para verificar que funcione correctamente y ver si la lógica de tu modelo pasa la prueba (debes estar en modo de desarrollo para ejecutar pruebas de datos).

Hay varias formas de iniciar pruebas de datos en un proyecto:

1. Si ajustas la configuración del proyecto para requerir que se aprueben las pruebas de datos antes de implementar los archivos en la producción, el IDE presentará el botón Ejecutar pruebas después de que confirmes los cambios en el proyecto. Se ejecutarán todas las pruebas de tu proyecto, sin importar qué archivo defina la prueba. Debes pasar las pruebas de datos antes de implementar los cambios en la producción.
2. Haz clic en el botón Run Data Tests en el panel Project Health. Esto ejecutará todas las pruebas de datos en tu proyecto, sin importar qué archivo defina la prueba.
3. Selecciona la opción Run LookML Tests en el menú del archivo. Solo se ejecutarán las pruebas que se definen en el archivo actual.

Una vez que ejecutes las pruebas de datos, el panel Project Health te mostrará el progreso y los resultados:

Puede hacer clic en el vínculo Explorar consulta para abrir una página Explorar con la consulta definida en la prueba de datos.

explore_source

El parámetro explore_source de una prueba de datos usa la misma sintaxis y lógica que el parámetro explore_source de una tabla derivada. La única diferencia es que el explore_source de una prueba de datos no admite los subparámetros derived_column, bind_filters y bind_all_filters.

Sugerencia práctica: Una forma sencilla de obtener el LookML de explore_source es usar una exploración existente para crear tu consulta, luego selecciona Obtener LookML en el menú de ajustes de Explorar y haz clic en la pestaña Tabla derivada para obtener la LookML de la consulta. Consulte nuestra documentación sobre cómo crear tablas derivadas nativas para obtener más información.

Ten en cuenta lo siguiente para la explore_source de una prueba de datos:

• La consulta explore_source de una prueba de datos es una consulta estándar de Looker, lo que significa que la consulta explore_source de la prueba tiene un límite de 5,000 filas. Asegúrate de que tu búsqueda no supere las 5,000 filas a fin de obtener un conjunto de resultados completo para probar. Puedes incorporar filtros o ordenar en tu explore_source para reducir la cantidad de filas en tu consulta o colocar las filas relevantes en la parte superior de la consulta.

• Un explore con extension: required no se puede usar como explore_source para una prueba de datos. El validador de LookML generará un error que indica que no se puede encontrar el explore_source.

assert

El subparámetro assert define los criterios por los que el resultado de la consulta explore_source se considera válido. El subparámetro expression acepta una expresión de Looker que da como resultado una yesno (booleano). Después de que se ejecuta la consulta explore_source, la expresión de la aserción se evalúa para cada fila del conjunto de resultados de la consulta. Si hay una respuesta no para cualquier fila de la consulta, la prueba de datos falla. Si la consulta en sí tiene errores, la prueba también fallará.

Una prueba puede tener varias declaraciones assert. Para pasar la prueba, cada aserción debe ser verdadera para cada fila de la consulta explore_source.

Sugerencia práctica: Puedes usar el cuadro de diálogo de cálculos de tablas para probar la sintaxis de expresión de Looker a fin de usarla en el parámetro expression de tu prueba.

Para usarlos en pruebas de datos, los campos de la expresión de Looker deben tener alcance completo, lo que significa que se especifican con el formato view_name.field_name. Por ejemplo, la siguiente expresión declara el campo como aircraft_engine_types.aircraft_engine_type_id:

assert: engine_type_id_not_null {
  expression: NOT is_null(${aircraft_engine_types.aircraft_engine_type_id}) ;;
}

Ejemplos

Cómo garantizar que una clave primaria sea única

En la siguiente prueba de datos, se crea una consulta de la exploración de orders y se define un expression para probar que los ID de pedido sean únicos en el conjunto de resultados. La consulta explore_source crea un recuento de las filas asociadas con cada ID en la base de datos. Si el ID es único, la base de datos debe tener solo una fila para un ID. Además, ordena el recuento y limita el conjunto de resultados a una fila, por lo que la respuesta a la consulta será el ID con el recuento más alto. Si algún ID tiene un recuento superior a 1, sabemos que hay varias filas para ese ID y, por lo tanto, el ID no es único. Si ese es el caso, la prueba de datos fallará.

test: order_id_is_unique {
  explore_source: orders {
    column: id {}
    column: count {}
    sorts: [orders.count: desc]
    limit: 1
  }
  assert: order_id_is_unique {
    expression: ${orders.count} = 1 ;;
  }

Verifica un valor conocido

La siguiente prueba de datos verifica que el valor de ingresos de 2017 sea siempre de USD 626,000. En este conjunto de datos, ese es un valor conocido que nunca debe cambiar.

test: historic_revenue_is_accurate {
  explore_source: orders {
    column: total_revenue {
      field: orders.total_revenue
    }
    filters: [orders.created_date: "2017"]
  }
  assert: revenue_is_expected_value {
    expression: ${orders.total_revenue} = 626000 ;;
  }
}

Confirma que no hay valores nulos

La siguiente prueba de datos comprueba que no haya valores nulos en los datos. Este explore_source usa un sort para garantizar que se muestren los nulos en la parte superior de la consulta. El ordenamiento por valores nulos puede variar en función del dialecto. En la siguiente prueba, se usa desc: yes como ejemplo.

test: status_is_not_null {
  explore_source: orders {
    column: status {}
    sorts: [orders.status: desc]
    limit: 1
  }
  assert: status_is_not_null {
    expression: NOT is_null(${orders.status}) ;;
  }
}