Risposta.

Storia della questione
Il controllo manuale della logica di business in SQL (a livello di stored procedure, funzioni, trigger) porta a errori che emergono solo in produzione. Per molto tempo, il test degli scenari SQL è stato informale e non standardizzato. Tuttavia, lo sviluppo delle tecnologie CI/CD richiede test automatizzati anche per il codice SQL.

Problema
La maggior parte degli sviluppatori si limita a testare a livello di applicazione. L'assenza di verifica delle procedure e funzioni SQL stesse porta a difetti che non vengono coperti da alcun pacchetto di test, ad esempio, quando cambia la logica delle UDF o si verificano regressioni nei report.

Soluzione
Nei processi di lavoro dei team moderni si organizzano test unitari e di integrazione direttamente per il codice SQL. Per il test unitario si utilizzano framework come tSQLt (SQL Server), utPLSQL (Oracle), pgTAP (PostgreSQL), mentre per l'integrazione si utilizzano ambienti separati per l'innalzamento di database temporanei, l'applicazione di migrazioni e la verifica degli scenari di business.

Esempio di test unitario su pgTAP:

-- Verifica la separazione degli stipendi
SELECT plan(2);
SELECT is( (SELECT calc_salary(1)), 1000, 'Stipendio per l'utente 1 corretto' );
SELECT isnt( (SELECT calc_salary(2)), 0, 'Lo stipendio dell'utente 2 non è zero' );
SELECT finish();

Codice del test di integrazione per CI/CD:

psql -U user -d testdb < migrations.sql
psql -U user -d testdb < test_data.sql
psql -U user -d testdb -c "SELECT * FROM my_procedure_test();"

Caratteristiche chiave:

I test devono essere isolati e avere un insieme di dati indipendente (setup/teardown).
Esecuzione automatica dei test nel pipeline CI/CD.
Verifica non solo della correttezza dei dati, ma anche di errori/situazioni limite/condizioni di uscita.

Domande trabocchetto.

È possibile fare a meno dei test automatici solo a livello di applicazione, se le procedure sono grandi? No, perché i test UI/API non garantiscono la correttezza del funzionamento della logica SQL (ad esempio, condizioni errate all'interno delle funzioni memorizzate o violazioni durante l'aggiornamento dei dati). I test unitari devono coprire tutte le ramificazioni di esecuzione nel codice SQL stesso.

Bastano i "lanci manuali" degli script di test — d'altronde nel database ci sono pochi cambiamenti? Non basta, anche nei piccoli progetti si presentano bug dopo cambiamenti nella schema o nella logica. L'automazione dei test nel processo CI riduce il fattore umano e previene le regressioni.

È possibile testare solo le procedure "critiche", saltando il resto? Il miglior approccio è coprire il maggior numero possibile di funzioni, specialmente se in futuro il codice sarà modificato da più team: i calcoli non evidenti e i casi limite si manifestano più frequentemente proprio nei rami non standard.

Errori tipici e anti-pattern

Assenza di setup/teardown → i test influenzano l'uno sull'altro
Copertura solo di scenari "positivi", assenza di test negativi
Struttura dei dati di test complessa/non manutenibile

Esempio dalla vita reale

Caso negativo

Durante la modifica della procedura di calcolo degli sconti abbiamo testato manualmente un paio di casi, tralasciando i principali rami della logica. In produzione, i clienti hanno iniziato a ricevere sconti errati, ed è stato necessario del tempo per sistemare la situazione.

Vantaggi:
Risparmio di tempo all'inizio.

Svantaggi:
Perdite a causa di correzioni manuali, disagio durante le modifiche e il refactoring.

Caso positivo

Abbiamo sviluppato test unitari con pgTAP per tutte le UDF e procedure chiave, i test di integrazione vengono eseguiti tramite CI ad ogni merge del ramo. Gli errori e le regressioni vengono identificati prima della distribuzione.

Vantaggi:
Stabilità delle funzioni, possibilità di modificare rapidamente la logica di business, bug minimi in produzione.

Svantaggi:
Richiesta di impegno di tempo per l'avvio e la manutenzione del database di test.