In che modo test unitario / utilizzo dei metodi TDD per ETL e progetti di reporting?

I progetti ETL sono progetti creati utilizzando uno strumento ETL (Estrai - Trasforma - Carica) come SSIS, PowerCenter, ecc

Ciò comporta in genere la lettura di dati da un'origine esterna, il caricamento in un database di gestione temporanea, l'esecuzione di determinate trasformazioni e il caricamento in un database finale

Un semplice esempio potrebbe essere quello di utilizzare SSIS per leggere i file Excel forniti dagli insegnanti che usano SSIS e caricarli in un database. Quindi scrivere le procedure memorizzate o più pacchetti SSIS per calcolare i voti di ogni studente e caricare tali dati in un data mart \ warehouse

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

Sto cercando di capire come eseguire TDD e test di unità adeguati in questo scenario. I test per ETL riguardano principalmente la garanzia che i dati caricati nelle corrispondenze delle tabelle di gestione temporanea siano il sottoinsieme corretto dei dati dall'origine. Quindi l'implementazione di un test 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 fregati

Esempio:

Sprint 1: la tabella Studenti contiene Nome, Età, Grado

Si creano dati di test per questa tabella e test unitari 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 di genere, i casi di test vengono invalidati dalla modifica dei dati. E se non lo fai, non puoi creare casi di test che richiedono la colonna del genere

Quello che ho fatto in passato è utilizzare lo sviluppo guidato dai test di accettazione . Il codice ETL è spesso distribuito in diverse fasi / lingue e tecnologie E strettamente accoppiato. La maggior parte del processo ETL dipende 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, mi assicurerei che coprisse anche il sequenziamento.

Mi concentrerei su TDD per ogni sequenza di trasformazione unica o almeno includerei questi test in una suite di test più ampia. Se ci sono troppe combinazioni, potresti dover scegliere le sequenze da testare. L'idea è di convalidare la pipeline ETL per i set di dati su cui verranno utilizzati. Oltre a assicurarti di avere una copertura di prova su tutto il tuo codice.

ETL può essere fatto con TDD e test in modo abbastanza simile alla maggior parte dei progetti, ad es

scrivere un test che non riesce (rosso) correggere l'errore (verde) rendere il codice perforabile e mantenibile (refactor)

Quindi per ETL potrebbe essere:

• scrivere uno script per caricare 1 record
• fail (nessuna origine dati definita)
• definisci sorgente [verde]
• nessun bisogno di refactor
• scrivere un test per caricare 1 record con 1 solo campo compilato
• fail (nessun codice scritto per quel campo)
• definire i dettagli del codice per quel campo
• refactoring
• definire test non riusciti che cercano attributi con valori validi [rosso]
• eccetera