Utilizzo
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 ;; } }
|
Gerarchia
test- o - test- o - test |
Valore predefinito
Nessuno
Accetta
L'identificatore del test dei dati, più i sottoparametri che definiscono le asserzioni e la query del test.
|
Definizione
Looker dispone dello strumento di convalida LookML per verificare che il codice LookML sia sintatticamente valido e dello strumento di convalida dei contenuti per verificare i riferimenti agli oggetti tra i contenuti e il modello.
Oltre a questi strumenti di convalida, il parametro test consente di convalidare la logica del modello. Per ogni test dei dati, crei una query e un'istruzione di asserzione yesno. Il test dei dati esegue la query di test e verifica che l'asserzione sia vera per ogni riga della query di test. Se l'istruzione di asserzione restituisce yes per ogni riga della query di test, il test dei dati viene superato.
Se le impostazioni progetto sono configurate in modo da richiedere il superamento dei test dei dati prima del deployment in produzione e se il progetto ha uno o più test parametri, l'IDE visualizzerà il pulsante Esegui test dopo l'esecuzione del commit delle modifiche al progetto. Gli sviluppatori LookML devono eseguire i test dei dati prima di eseguire il deployment delle modifiche in produzione.
Indipendentemente dal fatto che il progetto richieda o meno i test dei dati prima del deployment in produzione, uno sviluppatore LookML in modalità di sviluppo può eseguire i test dei dati in qualsiasi momento per verificare la logica del modello.
Puoi creare test dei dati nei file modello, nei file vista o in file di test dei dati dedicati separati . Quando utilizzi un file dedicato per ospitare i test dei dati, ricorda di include il file di test dei dati in qualsiasi file del modello o file di vista in cui vuoi eseguire i test dei dati.
Un test dei dati non può avere lo stesso nome e explore_source di un altro test dei dati nello stesso progetto. Se utilizzi lo stesso explore_source per più test dei dati nel progetto, assicurati che i nomi dei test dei dati siano tutti univoci.
Il parametro test ha i seguenti sottoparametri:
explore_source: definisce la query da utilizzare nel test dei dati.assert: definisce un'espressione Looker eseguita su ogni riga della query di test per verificare i dati.
Dopo aver definito il codice LookML per il test, puoi eseguire il test dei dati per verificare che funzioni correttamente e per vedere se la logica del modello supera il test (devi essere in modalità di sviluppo per eseguire i test dei dati).
Esistono diversi modi per avviare i test dei dati per un progetto:

- Se le impostazioni del progetto sono configurate in modo da richiedere il superamento dei test dei dati prima del deployment dei file in produzione, l'IDE visualizzerà il pulsante Esegui test dopo il commit delle modifiche al progetto. In questo modo verranno eseguiti tutti i test per il progetto, indipendentemente dal file che definisce il test. Devi superare i test dei dati prima di poter eseguire il deployment delle modifiche in produzione.
- Nel riquadro Stato del progetto, seleziona il pulsante Esegui test dei dati. In questo modo verranno eseguiti tutti i test dei dati nel progetto, indipendentemente dal file che definisce il test.
- Seleziona l'opzione Esegui test LookML dal menu del file. In questo modo verranno eseguiti solo i test definiti nel file corrente.
Una volta eseguiti i test dei dati, il riquadro Stato del progetto visualizzerà l'avanzamento e i risultati.

Puoi selezionare il link Esplora query per ogni risultato del test per aprire un'esplorazione con la query definita nel test dei dati.
explore_source
Il parametro explore_source in un test dei dati utilizza la stessa sintassi e la stessa logica del parametro explore_source di una tabella derivata. L'unica differenza è che explore_source di un test dei dati non supporta i sottoparametri derived_column, bind_filters e bind_all_filters.
Suggerimento utile: un modo semplice per ottenere il codice LookML
explore_sourceè utilizzare un'esplorazione esistente per creare la query. Nell'esplorazione, seleziona Ottieni LookML dal menu a forma di ingranaggio dell'esplorazione e poi seleziona la scheda Tabella derivata per ottenere il codice LookML per la query. Per ulteriori informazioni, consulta la documentazione sulla creazione di tabelle derivate native.
Tieni presente quanto segue per explore_source di un test dei dati:
La query
explore_sourcedi un test dei dati è una query Looker standard, il che significa che la queryexplore_sourcedel test ha un limite di 5000 righe. Assicurati che la query non superi le 5000 righe in modo da ottenere un set di risultati completo da testare. Puoi incorporare filtri o ordinamenti inexplore_sourceper ridurre il numero di righe nella query o per portare le righe pertinenti in cima alla query.Un
exploreconextension: requirednon può essere utilizzato comeexplore_sourceper un test dei dati. Lo strumento di convalida LookML genererà un errore che indica che non è possibile trovareexplore_source.
assert
Il sottoparametro assert definisce i criteri in base ai quali il risultato della query explore_source è considerato valido. Il sottoparametro expression accetta un'espressione Looker che restituisce un valore yesno (booleano). Dopo l'esecuzione della query explore_source, l'espressione dell'asserzione viene valutata per ogni riga del set di risultati della query. Se viene restituita una risposta no per una riga della query, il test dei dati non viene superato. Se la query stessa presenta errori, anche il test non viene superato.
Un test può avere più dichiarazioni assert. Affinché il test venga superato, ogni asserzione deve essere vera per ogni riga della query explore_source.
Suggerimento utile: puoi utilizzare la finestra di dialogo calcoli tabellari per testare la sintassi dell'espressione Looker da utilizzare nel parametro
expressiondel test.
Per l'utilizzo nei test dei dati, i campi nell'espressione Looker devono essere completamente definiti, ovvero specificati utilizzando il formato view_name.field_name. Ad esempio, l'espressione seguente dichiara il campo come aircraft_engine_types.aircraft_engine_type_id:
assert: engine_type_id_not_null {
expression: NOT is_null(${aircraft_engine_types.aircraft_engine_type_id}) ;;
}
Esempi
Garantire che una chiave primaria sia univoca
Il seguente test dei dati crea una query dall'esplorazione orders e definisce un'espressione expression per verificare che gli ID ordine siano univoci nel set di risultati. La query explore_source crea un conteggio delle righe associate a ogni ID nel database. Se l'ID è univoco, il database deve avere una sola riga per un ID. Inoltre, ordina in base al conteggio e limita il set di risultati a una riga, quindi la risposta della query sarà l'ID con il conteggio più alto. Se un ID ha un conteggio superiore a 1, sappiamo che esistono più righe per quell'ID e quindi l'ID non è univoco. In questo caso, il test dei dati non verrà superato.
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 ;;
}
Verificare un valore noto
Il test dei dati successivo verifica che il valore delle entrate del 2017 sia sempre di 626.000 $. In questo set di dati, si tratta di un valore noto che non deve mai cambiare.
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 ;;
}
}
Confermare che non esistono valori null
Il test dei dati successivo verifica che non esistano valori null nei dati. Questo explore_source utilizza un sort per assicurarsi che tutti i valori null vengano restituiti nella parte superiore della query. L'ordinamento per i valori null può variare a seconda del dialetto. Il seguente test utilizza desc: yes come esempio.
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}) ;;
}
}