Test di automazione per il flusso ETL

Quello che stai descrivendo è un test end-to-end. Questo è un modo per convalidare il tuo sistema e ha alcuni vantaggi: garantisce che ogni parte del sistema funzioni.

Il rovescio della medaglia è che colpisce ogni parte del tuo sistema, il che può renderlo lento da configurare e tenderà a essere fragile (cambiare una cosa può rompere numerose altre parti).

Un approccio comune, e quello che raccomanderei, è quello di rompere le funzioni di trasformazione e testare quelle esplicitamente con i test unitari. Ciò richiederà di scrivere il programma in un modo che permetta di richiamare il codice di trasformazione senza il codice di lettura del file o di accesso al database. Ciò ha alcuni importanti vantaggi: se, in pochi anni, qualcuno decide che desiderano che queste trasformazioni si verifichino all'interno di un'altra applicazione, possono riutilizzare solo il codice di trasformazione (senza dover capire come suddividerlo separatamente dal resto).

Quindi, finirai con un gruppo di test unitari, che testano piccole parti specifiche del codice - per esempio, "un input di 3 record dovrebbe risultare in 3 inserimenti di database", "un input di 3 record, uno dei quali esiste già nel database, dovrebbe comportare solo 2 inserimenti nel database "," richiamare la trasformazione su un record che manca un campo obbligatorio deve generare un'eccezione ", ecc.

Per configurarlo, è probabile che sia necessario convertire il lettore di file e il masterizzatore di database in interfacce. Quindi implementate la versione che funziona "per davvero", così come impostando una versione che pretende di fare, ma in realtà sta solo confermando che è stato chiamato il codice previsto. Non è necessario scrivere esplicitamente queste classi false, la maggior parte delle lingue dispone di librerie che gestiranno questo processo (chiamato "mocking") per te.

Quindi, una volta che hai tutto pronto, avrai un sacco di test unitari che confermano specifiche funzionalità nel codice di trasformazione.

C'è un lotto in più che va bene nella scrittura di software testabile, ma questo dovrebbe almeno farti pensare nella giusta direzione. Se vuoi modificare la tua domanda per includere in quale lingua si trova il software, posso indicarti alcuni strumenti specifici per il tuo caso d'uso. Senza conoscere il tuo caso d'uso preciso, posso almeno consigliare di cercare "software testabile per scrivere" e leggere un po '.

I'm not sure if I should test the DB's values or the "transformers" functions in my code

Fai entrambe le cose.

Non conosciamo il tuo design ma, ciò che abbiamo qui sono tre diversi timori che, in teoria, dovrebbero essere fatti per testare indipendentemente gli uni dagli altri.

Suppongo che -almeno- hai implementato i test unitari per ogni E(xtract) , T(ransform) e L(oad) come gli sviluppi come elaborati. Questi sono i tuoi primi test automatici.

Un altro tipo di test che considero un must sono i test di integrazione.

A questo punto, per integrazione, intendo "l'assemblaggio" dei componenti. Come si comportano tutti insieme lavorando senza il DB o i file CSV.

Gli ingressi e le uscite possono essere eseguiti in memoria. Ad esempio, utilizzando gli array come input e collezioni come output. Dipenderà molto dal tuo design. Ad esempio, se hai implementato il pattern di repository, dovrebbe essere facile per te prendere in giro i metodi load e save . Lo stesso vale per i lettori CSV, fondamentalmente perché questi file sono anche un'origine dati a cui è possibile anche astrarre l'accesso.

Questi sono i tuoi secondi test automatici.

Quando dico automatizzato, volevo dire che questi test sono eseguiti automaticamente durante la fase di costruzione o di confezionamento. Non ho familiarità con la tecnologia dello stack PHP, ma presumo che PHP abbia già diverse librerie e strumenti indirizzati a questo scopo.

Per quanto riguarda i test end-to-end, se non puoi permetterti di implementare un database in memoria, non vedo perché non dovresti fare test contro il vero DB. Non penserei che questo testasse i valori di DB. Assicurati di poter ripristinare lo stato del DB alla fine del piano di test (ad esempio, eliminando le righe).

Come automatizzare i test end-to-end è una domanda abbastanza ampia. Troverete diversi strumenti rivolti a questo scopo. Mi piacciono particolarmente quelli che mi consentono di progettare casi d'uso in modo dichiarativo. Ad esempio da script. Li ho trovati facili da integrare con CI.

Qui una rappresentazione visiva del piano di test suggerito sopra. Ogni colore appartiene a un diverso insieme di test.