Come si esegue il test unitario \ utilizzare i metodi TDD per ETL e progetti di reporting?

11

I progetti ETL sono progetti creati utilizzando uno strumento ETL (Extract - Transform - Load) come SSIS, PowerCenter, ecc.

In genere ciò comporta la lettura di dati da un'origine esterna, il caricamento in un database di staging, l'esecuzione di determinate trasformazioni e il caricamento in un database finale

Un semplice esempio potrebbe essere utilizzare SSIS per leggere i file excel forniti dagli insegnanti che utilizzano SSIS e caricarli in un database. Quindi scrivi stored procedure o più pacchetti SSIS per calcolare i voti di ogni studente e caricare i dati in un data mart \ warehouse

Quindi si creano stored procedure sul mart per generare output che viene utilizzato dagli strumenti di reporting (SSRS \ Excel \ etc) per generare visualizzazioni.

Sto cercando di capire come eseguire il TDD e il corretto test delle unità in questo scenario. I test per gli ETL si basano principalmente sull'assicurare che i dati caricati nelle corrispondenze delle tabelle di staging siano il giusto sottoinsieme dei dati dall'origine. Quindi implementare un test per questo porta all'implementazione di una versione mini dell'ETL. L'output degli SP del report dipende dai dati nelle tabelle stesse, quindi non è possibile avere un set stabile di dati di output senza un incubo di manutenzione anche se si crea un database contenente dati di test puliti

Esempio:

Sprint 1: la tabella dello studente contiene nome, età, grado

Crea dati di test per questa tabella e unit test basati su quello

Sprint 2: un campo di genere viene aggiunto alla tabella.

Ora, se si aggiornano i dati nel campo studente per popolare l'attributo gender, i test case vengono invalidati poiché i dati sono stati modificati. E se non lo fai, non puoi creare casi di test che richiedono la colonna di genere

    
posta user87166 07.04.2015 - 19:00
fonte

2 risposte

2

Quello che ho fatto in passato è usare Sviluppo guidato dai test di accettazione . Il codice ETL è spesso distribuito tra diversi stadi / linguaggi e tecnologie E strettamente accoppiato. La maggior parte dei processi ETL dipendono dalla sequenza di trasformazioni nella pipeline.

Il rischio nell'uso del test unitario solo in ETL è che non coprirà le integrazioni. Il sequenziamento delle trasformazioni è una parte uguale alle trasformazioni effettive in molti ETL. Se sto spendendo risorse per la creazione di una suite di test automatizzata, farei in modo che riguardi anche il sequenziamento.

Mi concentrerei su TDD per ciascuna sequenza di trasformazione unica o almeno includo questi test in una suite di test più ampia. Se ci sono troppe combinazioni, potrebbe essere necessario scegliere le sequenze da testare. L'idea è di convalidare la pipeline ETL per i set di dati su cui sarà utilizzata. Oltre ad assicurarti di avere una copertura di prova su tutto il tuo codice.

    
risposta data 03.05.2015 - 20:43
fonte
0

ETL può essere fatto con TDD e funziona in modo simile alla maggior parte dei progetti, cioè

scrivi un test che fallisce (rosso) correggi l'errore (verde) rendere il codice performent & mantenibile (refactor)

Quindi per ETL che potrebbe essere:

  • scrivi uno script per caricare 1 record
  • fail (nessuna origine dati definita)
  • definisce la fonte [verde]
  • nessun refactator necessario
  • scrivi un test per caricare 1 record con solo 1 campo compilato
  • fail (nessun codice scritto per quel campo)
  • definisce i dettagli del codice per quel campo
  • refactoring
  • definisce i test non riusciti che cercano attributi con valori validi [rosso]
  • etc
risposta data 08.04.2015 - 00:42
fonte

Leggi altre domande sui tag