Antwoord.

Historie van de vraag
Handmatige controle van bedrijfslogica in SQL (op het niveau van opgeslagen procedures, functies, triggers) leidt tot fouten die alleen in productie naar voren komen. Lange tijd was het testen van SQL-scripts informeel en niet gestandaardiseerd. De ontwikkeling van CI/CD-technologieën vereist echter geautomatiseerde tests voor SQL-code.

Probleem
De meeste ontwikkelaars beperken zich tot testen op applicatieniveau. Het ontbreken van controles van de SQL-procedures en functies leidt tot defecten die door geen enkele testpakket worden gedekt — bijvoorbeeld bij wijzigingen in de logica van UDF of regressie in rapportages.

Oplossing
In de werkprocessen van moderne teams worden eenheden- en integratietests direct voor de SQL-code georganiseerd. Voor eenheidstesten worden frameworks zoals tSQLt (SQL Server), utPLSQL (Oracle), pgTAP (PostgreSQL) gebruikt, en voor integratietests aparte omgevingen voor het opzetten van tijdelijke databases, het toepassen van migraties en het controleren van bedrijfs-scenario's.

Een voorbeeld van een eenheidstest op pgTAP:

-- Controleer het salarisdepartement
SELECT plan(2);
SELECT is( (SELECT calc_salary(1)), 1000, 'Salaris voor gebruiker 1 correct' );
SELECT isnt( (SELECT calc_salary(2)), 0, 'Salaris van gebruiker 2 is niet nul' );
SELECT finish();

Code voor een integratietest voor 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();"

Belangrijke kenmerken:

Tests moeten geïsoleerd zijn, met een onafhankelijke dataset (setup/teardown).
Automatische uitvoering van tests in de CI/CD pipeline.
Controle niet alleen op gegevenscorrectheid, maar ook op fouten/grensgevallen/uitgangsvoorwaarden.

Vragen met een valstrik.

Kun je alleen met autotests op applicatieniveau volstaan als de procedures groot zijn? Nee, omdat UI/API-tests niet de correctheid van de SQL-logica garanderen (bijvoorbeeld onjuiste voorwaarden binnen opgeslagen functies of schendingen bij gegevensupdates). Eenheidstests moeten alle worteltakken van uitvoeringen in de SQL-code dekken.

Is het voldoende om "handmatige" test-scripts uit te voeren, want er zijn weinig wijzigingen in de database? Niet genoeg, zelfs in kleine projecten komen bugs voor na wijzigingen in het schema of de logica. Automatisering van testen in het CI-proces vermindert de menselijke factor en voorkomt regressies.

Kun je alleen "kritieke" procedures testen en de rest overslaan? De beste aanpak is om zoveel mogelijk functies te dekken, vooral als in de toekomst de code door meerdere teams wijzigt: onduidelijke berekeningen en edge-cases verschijnen vaak in niet-standaard takken.

Typische fouten en anti-patronen

Ontbreken van setup/teardown → tests beïnvloeden elkaar
Alleen "positieve" scenario's dekken, geen negatieve tests
Complex/onondersteunde structuur van testgegevens

Voorbeeld uit het leven

Negatieve case

Bij het verbeteren van de procedure voor het berekenen van kortingen werden handmatig een paar cases getest, de belangrijkste takken van de logica werden over het hoofd gezien. In de productie begonnen klanten onjuiste kortingen te ontvangen, wat enkele dagen om op te lossen kostte.

Voordelen:
Tijdswinst aan het begin.

Nadelen:
Verlies aan handmatig corrigeren, ongemak bij verbeteringen en refactoringen.

Positieve case

We hebben eenheidstests met pgTAP ontwikkeld voor alle belangrijke UDF's en procedures, integratietests worden via CI uitgevoerd bij elke merge van de tak. Fouten en regressies worden vóór implementatie ontdekt.

Voordelen:
Stabiliteit van functies, mogelijkheid om snel bedrijfslogica bij te werken, minimale bugs in productie.

Nadelen:
Vereist tijdsinvestering voor het opstarten en onderhouden van de testdatabase.