teste

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 ;;
  }
}
Hierarquia
test

- ou -

test

- ou -

test
Valor padrão
Nenhum

Aceita
O identificador do teste de dados, além de subparâmetros que definem as declarações e a consulta do teste.

Definição

O Looker tem o validador do LookML para verificar se o código do LookML é sintaticamente válido e o validador de conteúdo para verificar referências de objetos entre o conteúdo e o modelo.

Além desses validadores, o parâmetro test permite validar a lógica do modelo. Para cada teste de dados, você cria uma consulta e uma instrução de declaração yesno. O teste de dados executa a consulta de teste e verifica se a declaração é verdadeira para cada linha da consulta de teste. Se a instrução de declaração retornar yes para cada linha da consulta de teste, o teste de dados será aprovado.

Se as configurações do projeto estiverem configuradas para exigir que os testes de dados sejam aprovados antes da implantação na produção e se o projeto tiver um ou mais parâmetros test, o ambiente de desenvolvimento integrado vai apresentar o botão Executar testes depois que você confirmar as mudanças no projeto. Os desenvolvedores do LookML precisam executar os testes de dados antes de implantar mudanças na produção.

Independentemente de o projeto exigir testes de dados antes da implantação na produção, um desenvolvedor do LookML no modo de desenvolvimento pode executar testes de dados a qualquer momento para verificar a lógica do modelo.

É possível criar testes de dados em arquivos de modelo, arquivos de visualização ou em arquivos de teste de dados dedicados separados. Ao usar um arquivo dedicado para hospedar os testes de dados, lembre-se de include o arquivo de teste de dados em qualquer arquivo modelo ou arquivo de visualização em que você queira executar os testes de dados.

Um teste de dados não pode ter o mesmo nome e explore_source que outro teste de dados no mesmo projeto. Se você estiver usando o mesmo explore_source para vários testes de dados no projeto, verifique se os nomes dos testes de dados são exclusivos.

O parâmetro test tem os seguintes subparâmetros:

  • explore_source: define a consulta a ser usada no teste de dados.
  • assert: define uma expressão do Looker que é executada em cada linha da consulta de teste para verificar os dados.

Depois de definir o LookML para o teste, você pode executar o teste de dados para verificar se ele funciona corretamente e se a lógica do modelo passa no teste. É necessário estar no modo Desenvolvimento para executar testes de dados.

Há várias maneiras de iniciar testes de dados para um projeto:

  1. Se as configurações do projeto estiverem configuradas para exigir que os testes de dados sejam aprovados antes de implantar os arquivos na produção, o ambiente de desenvolvimento integrado vai apresentar o botão Executar testes depois que você confirmar mudanças no projeto. Isso vai executar todos os testes do projeto, não importa qual arquivo define o teste. É necessário aprovar os testes de dados antes de implantar as mudanças na produção.
  2. No painel Integridade do projeto, selecione o botão Executar testes de dados. Isso vai executar todos os testes de dados no projeto, não importa qual arquivo define o teste.
  3. Selecione a opção Executar testes do LookML no menu do arquivo. Isso vai executar apenas os testes definidos no arquivo atual.

Depois de executar os testes de dados, o painel Integridade do projeto vai mostrar o progresso e os resultados.

É possível selecionar o link Consulta de análise para cada resultado do teste para abrir uma análise com a consulta definida no teste de dados.

explore_source

O parâmetro explore_source em um teste de dados usa a mesma sintaxe e lógica do parâmetro explore_source de uma tabela derivada. A única diferença é que o explore_source de um teste de dados não oferece suporte aos subparâmetros derived_column, bind_filters e bind_all_filters.

Dica útil: uma maneira fácil de acessar o LookML explore_source é usar uma análise atual para criar a consulta. Na análise, selecione Acessar LookML no menu de engrenagem da análise e selecione a guia Tabela derivada para acessar o LookML da consulta. Consulte a documentação sobre como criar tabelas derivadas nativas para mais informações.

Observe o seguinte para o explore_source de um teste de dados:

  • A consulta explore_source de um teste de dados é uma consulta padrão do Looker, o que significa que a consulta explore_source do teste tem um limite de 5.000 linhas. Verifique se a consulta não excede 5.000 linhas para receber um conjunto de resultados completo para teste. É possível incorporar filtros ou classificação no explore_source para reduzir o número de linhas na consulta ou para trazer as linhas relevantes para a parte de cima da consulta.

  • Um explore com extension: required não pode ser usado como um explore_source para um teste de dados. O validador do LookML vai gerar um erro informando que o explore_source não pode ser encontrado.

assert

O subparâmetro assert define os critérios pelos quais o resultado da consulta explore_source é considerado válido. O subparâmetro expression aceita uma expressão do Looker que resulta em um yesno (booleano). Depois que a consulta explore_source é executada, a expressão da declaração é avaliada para cada linha do conjunto de resultados da consulta. Se houver uma resposta no para qualquer linha da consulta, o teste de dados vai falhar. Se a consulta tiver erros, o teste também vai falhar.

Um teste pode ter várias declarações assert. Para que o teste seja aprovado, cada declaração precisa ser verdadeira para cada linha da consulta explore_source.

Dica útil: é possível usar a caixa de diálogo de cálculos de tabela para testar a sintaxe da expressão do Looker a ser usada no parâmetro expression do teste.

Para uso em testes de dados, os campos na expressão do Looker precisam ser totalmente definidos, ou seja, especificados usando o formato view_name.field_name. Por exemplo, a expressão a seguir declara o 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}) ;;
}

Exemplos

Como garantir que uma chave primária seja exclusiva

O teste de dados a seguir cria uma consulta na análise orders e define uma expression para testar se os IDs de pedidos são exclusivos no conjunto de resultados. A consulta explore_source cria uma contagem de linhas associadas a cada ID no banco de dados. Se o ID for exclusivo, o banco de dados terá apenas uma linha para um ID. Além disso, ele classifica a contagem e limita o conjunto de resultados a uma linha. Assim, a resposta da consulta será o ID com a contagem mais alta. Se algum ID tiver uma contagem maior que 1, sabemos que há várias linhas para esse ID e, portanto, o ID não é exclusivo. Nesse caso, esse teste de dados vai falhar.

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 ;;
  }

Como verificar um valor conhecido

O próximo teste de dados verifica se o valor da receita de 2017 é sempre de US $626.000. Nesse conjunto de dados, esse é um valor conhecido que nunca deve mudar.

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 ;;
  }
}

Como confirmar que não há valores nulos

O próximo teste de dados verifica se não há valores nulos nos dados. Esse explore_source usa uma sort para garantir que todos os valores nulos sejam retornados na parte de cima da consulta. A classificação de valores nulos pode variar de acordo com o dialeto. O teste a seguir usa desc: yes como exemplo.


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}) ;;
  }
}