Testare i passaggi della pipeline con asserzioni

Una pipeline di dati che viene eseguita senza errori può comunque produrre un output errato senza segnalarlo: righe eliminate da un filtro sbagliato, una colonna moltiplicata per il fattore errato oppure un merge che duplica le righe perché la chiave di join non era univoca. L'unico modo per individuare questi errori silenziosi consiste nell'inserire asserzioni che verifichino le proprietà attese dei dati in ogni fase della pipeline. Le asserzioni trasformano gli errori logici in errori evidenti e immediatamente visibili.

Dopo ogni passaggio di filtraggio, verifichi con un'asserzione che il numero di righe risultante rientri nell'intervallo previsto. Un numero troppo basso indica che il filtro era eccessivamente restrittivo; un numero troppo alto indica che un join ha duplicato dei record. Esprima l'intervallo previsto come frazione dell'input: per esempio, in dati integri un passaggio che elimina i valori nulli non dovrebbe mai rimuovere più del 30 % delle righe. Questa protezione individua cambiamenti imprevisti nella qualità dei dati sorgente.

Verifichi con un'asserzione che tutte le colonne di output previste esistano dopo ogni funzione di trasformazione. Se un passaggio di rinomina usa accidentalmente la chiave sbagliata, la colonna risultante sarà assente e l'errore emergerà solo molto più avanti, quando un altro passaggio tenterà di utilizzarla. Un'asserzione subito dopo la trasformazione individua il problema alla sua origine, invece di farlo emergere tre passaggi dopo con un KeyError poco chiaro.

Dopo aver calcolato una colonna dei ricavi, verifichi con un'asserzione che non contenga valori negativi. Dopo aver analizzato le date, verifichi che rientrino nell'intervallo di anni previsto. Dopo aver codificato le categorie, verifichi che non compaiano codici imprevisti. Ogni asserzione è un contratto sui dati che documenta il comportamento previsto e individua tempestivamente le violazioni. Le scriva come asserzioni anziché come istruzioni di stampa, in modo che generino errori nelle esecuzioni automatizzate della pipeline.

Un errore comune nei dati è un merge molti-a-molti che moltiplica accidentalmente le righe. Dopo ogni pd.merge(), verifichi con un'asserzione che il numero di righe sia quello previsto: in genere, per un left join, non dovrebbe superare il numero di righe del DataFrame a sinistra. Verifichi inoltre che la colonna chiave sia univoca, se dovrebbe esserlo, così da individuare immediatamente i cross join accidentali.

Alcune colonne non devono mai contenere valori nulli in nessun punto della pipeline. Verifichi con un'asserzione df['key_col'].notna().all() dopo ogni passaggio che potrebbe introdurre accidentalmente valori nulli, ad esempio un merge che non riesce a trovare una corrispondenza per alcune righe (producendo NaN nelle colonne unite) oppure una chiamata a map() che restituisce NaN per i valori senza corrispondenza. Faccia in modo che queste asserzioni siano le ultime due righe di ogni funzione di trasformazione che modifica tali colonne.

Scriva unit test per ogni funzione della pipeline usando piccoli DataFrame creati manualmente, che isolino la logica da verificare. Ogni test dovrebbe: predisporre un input minimo, chiamare la funzione e verificare le proprietà dell'output. Per pipeline semplici è sufficiente usare l'assert integrato in Python; nei progetti più grandi, usi pytest per eseguire automaticamente tutti i test prima del deployment.

Test efficaci coprono non solo il percorso previsto, ma anche i casi limite: input completamente nullo, DataFrame vuoto, DataFrame con una sola riga e colonne con valori estremi. Un DataFrame vuoto dovrebbe restituire un DataFrame vuoto, non generare un errore. Un DataFrame con una sola riga dovrebbe produrre il risultato corretto. Testi esplicitamente questi casi per assicurarti che in produzione la pipeline li gestisca correttamente quando arrivano dati insoliti.

Oltre agli unit test sulle singole funzioni, scriva un test di integrazione che esegua la pipeline completa su un piccolo campione rappresentativo di dati reali. Verifichi con asserzioni che l'output abbia il numero previsto di colonne, che la colonna chiave sia univoca e che i ricavi totali rientrino in un intervallo plausibile. Questo controllo end-to-end individua i bug nell'interazione tra i passaggi che gli unit test non riescono a rivelare.

Man mano che la pipeline cresce, raccolga tutti i test in una directory tests/ ed esegua pytest dalla riga di comando. Un file conftest.py può creare fixture condivise, come DataFrame di esempio. Integri pytest nella pipeline CI/CD, in modo che ogni modifica al codice esegua automaticamente tutti i test prima del deployment. Un test non superato blocca il deployment, impedendo al codice non funzionante di arrivare in produzione.

Ogni asserzione nella pipeline è sia una protezione sia un elemento di documentazione: dichiara in una forma leggibile dalla macchina come devono apparire i dati in quel punto. Quando un nuovo analista entra nel progetto e legge il codice della pipeline, le asserzioni gli illustrano i contratti sui dati senza richiedere un documento di specifiche separato. Tratti ogni asserzione come farebbe con un commento: renda il messaggio abbastanza descrittivo da chiarire la regola di business che impone.

Verifichi la comprensione dei concetti di analisi dei dati presentati in questa lezione.

In questa lezione ha imparato a: inserire nella pipeline asserzioni per il controllo del numero di righe, dell'esistenza delle colonne, dell'intervallo dei valori e dei valori nulli, scrivere unit test per le singole funzioni di trasformazione includendo i casi limite e eseguire test di integrazione e trattare le asserzioni come documentazione vivente dei contratti sui dati. Ora vedremo come programmare e registrare le esecuzioni della pipeline per automatizzarle quotidianamente.