Uso
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 ;; } }
|
Jerarquía
testO bien: testO bien: test |
Valor predeterminado
Ninguno
Acepta
Es el identificador de la prueba de datos, además de los subparámetros que definen las aserciones y la consulta de la prueba.
|
Definición
Looker tiene el validador de LookML para verificar que tu código de LookML sea sintácticamente válido y el Validador de contenido para verificar las referencias de objetos entre tu contenido y tu 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 instrucción 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 instrucción de aserción devuelve yes para cada fila de la consulta de prueba, la prueba de datos se aprueba.
Si la configuración de tu proyecto está establecida para requerir que se aprueben las pruebas de datos antes de implementar en producción y si tu proyecto tiene uno o más parámetros test, el IDE mostrará el botón Ejecutar pruebas después de que confirmes los cambios en el proyecto. Los desarrolladores de LookML deben ejecutar las pruebas de datos antes de implementar cambios en producción.
Independientemente de si tu proyecto requiere pruebas de datos antes de la implementación en producción, un desarrollador de LookML 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 modelos, archivos de vistas o en archivos de pruebas de datos separados y específicos. Cuando uses un archivo dedicado para alojar tus pruebas de datos, recuerda include el archivo de prueba de datos en cualquier archivo de modelo o archivo de vista en el que desees ejecutar tus pruebas de datos.
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, podrás 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 el modo de desarrollo para ejecutar pruebas de datos).
Existen varias formas de iniciar pruebas de datos para un proyecto:

- Si la configuración de tu proyecto está establecida para requerir que se aprueben las pruebas de datos antes de implementar tus archivos en producción, el IDE mostrará el botón Ejecutar pruebas después de que confirmes los cambios en el proyecto. Se ejecutarán todas las pruebas de tu proyecto, independientemente del archivo que defina la prueba. Debes aprobar las pruebas de datos antes de implementar tus cambios en producción.
- En el panel Project Health, selecciona el botón Run Data Tests. Se ejecutarán todas las pruebas de datos de tu proyecto, independientemente del archivo que defina la prueba.
- Selecciona la opción Run LookML Tests en el menú del archivo. Solo se ejecutarán las pruebas definidas en el archivo actual.
Una vez que ejecutes las pruebas de datos, el panel Estado del proyecto mostrará el progreso y los resultados.

Puedes seleccionar el vínculo Explorar consulta para cada resultado de la prueba y abrir una exploración con la consulta definida en la prueba de datos.
explore_source
El parámetro explore_source en 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 parámetro explore_source de una prueba de datos no admite los subparámetros derived_column, bind_filters y bind_all_filters.
Sugerencia útil: Una forma sencilla de obtener el LookML de
explore_sourcees usar una exploración existente para crear tu consulta. En el Explorar, selecciona Obtener LookML en el menú de ajustes del Explorar y, luego, selecciona la pestaña Tabla derivada para obtener el LookML de la consulta. Consulta la documentación sobre cómo crear tablas derivadas nativas para obtener más información.
Ten en cuenta lo siguiente para el explore_source de una prueba de datos:
La consulta
explore_sourcede una prueba de datos es una consulta estándar de Looker, lo que significa que la consultaexplore_sourcede la prueba tiene un límite de 5,000 filas. Asegúrate de que tu consulta no supere las 5,000 filas para obtener un conjunto de resultados completo para probar. Puedes incorporar filtros u ordenamientos en tuexplore_sourcepara reducir la cantidad de filas en tu consulta o para llevar las filas pertinentes a la parte superior de la consulta.No se puede usar un
exploreconextension: requiredcomoexplore_sourcepara una prueba de datos. El Validador de LookML generará un error que indica que no se puede encontrar elexplore_source.
assert
El parámetro secundario assert define los criterios según los cuales se considera válido el resultado de la búsqueda explore_source. El subparámetro expression acepta una expresión de Looker que genera un valor yesno (booleano). Después de que se ejecuta la consulta explore_source, se evalúa la expresión de la aserción para cada fila del conjunto de resultados de la consulta. Si hay una respuesta no para alguna fila de la consulta, la prueba de datos falla. Si la consulta en sí tiene errores, la prueba también falla.
Una prueba puede tener varias declaraciones de assert. Para que la prueba se apruebe, cada aserción debe ser verdadera para cada fila de la consulta explore_source.
Sugerencia útil: Puedes usar el diálogo Cálculos basados en tablas para probar la sintaxis de la expresión de Looker que se usará en el parámetro
expressionde tu prueba.
Para usarse en pruebas de datos, los campos de la expresión de Looker deben tener un 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
La siguiente prueba de datos crea una consulta a partir de la exploración orders y define un expression para probar que los IDs de pedido sean únicos en el conjunto de resultados. La consulta explore_source crea un recuento de las filas asociadas a cada ID de la base de datos. Si el ID es único, la base de datos debería tener solo una fila para un ID. Además, ordena los resultados según el recuento y limita el conjunto de resultados a una fila, por lo que la respuesta de 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 es así, esta 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 ;;
}
Cómo verificar un valor conocido
Esta siguiente prueba de datos verifica que el valor de ingresos de 2017 siempre sea de USD 626,000. En este conjunto de datos, es un valor conocido que nunca debería 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 ;;
}
}
Confirmar que no hay valores nulos
La siguiente prueba de datos verifica que no haya valores nulos en los datos. Este explore_source usa un sort para asegurarse de que los valores nulos se devuelvan en la parte superior de la consulta. La clasificación de los valores nulos puede variar según tu 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}) ;;
}
}