Cevap.

Soru geçmişi
SQL’deki iş mantığının manuel kontrolü (saklı prosedürler, fonksiyonlar, tetikleyiciler seviyesinde) üretim ortamında ortaya çıkan hatalara yol açar. SQL senaryolarının test edilmesi uzun süre gayri resmi ve standart olmayan bir şekilde gerçekleştirildi. Ancak CI/CD teknolojilerinin gelişimi, SQL kodu için otomatik testlerin gerekliliğini doğurdu.

Sorun
Çoğu geliştirici sadece uygulama seviyesindeki testlerle sınırlı kalıyor. SQL prosedürlerinin ve fonksiyonlarının kontrol edilmemesi, UDF mantığındaki değişiklikler veya raporlardaki regresyon gibi hiçbir test paketi tarafından kapsanmayan hatalara yol açar.

Çözüm
Modern ekiplerin çalışma süreçlerinde SQL kodu için doğrudan birim ve entegrasyon testleri oluşturulmaktadır. Birim testi için tSQLt (SQL Server), utPLSQL (Oracle), pgTAP (PostgreSQL) gibi çerçeveler kullanılır, entegrasyon için ise geçici veritabanlarını başlatmak, göçleri uygulamak ve iş senaryolarını kontrol etmek için ayrı ortamlar oluşturulur.

pgTAP üzerindeki birim testi örneği:

-- Maaş ayrımını kontrol ediyoruz
SELECT plan(2);
SELECT is( (SELECT calc_salary(1)), 1000, 'Kullanıcı 1 için maaş doğru' );
SELECT isnt( (SELECT calc_salary(2)), 0, 'Kullanıcı 2 maaşı sıfır değildir' );
SELECT finish();

CI/CD için entegrasyon testi kodu:

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();"

Anahtar noktalar:

Testler izole olmalı ve bağımsız bir veri setine sahip olmalıdır (setup/teardown).
CI/CD pipeline'ında testlerin otomatik olarak çalıştırılması.
Verilerin doğruluğunu, hata/kenar durumlarını/çıktı koşullarını kontrol etme.

Tuzağa düşürücü sorular.

Büyük prosedürler varsa sadece uygulama seviyesindeki otomatik testlerle yetinmek mümkün mü? Hayır, çünkü UI/API testleri SQL mantığının doğru çalışmasını garanti etmez (örneğin, saklı fonksiyonlar içinde yanlış koşullar veya veri güncellemeleri sırasında ihlaller). Birim testleri SQL kodunun kendisindeki tüm temel yürütme dallarını kapsamalıdır.

Test scriptlerinin "manuel" çalıştırması yeterli mi - sonuçta veritabanında çok az değişiklik var? Yeterli değildir, küçük projelerde bile şemadaki veya mantıktaki değişikliklerden sonra hatalar ortaya çıkmaktadır. CI sürecinde test otomasyonu insan faktörünü azaltır ve regresyonları önler.

Sadece "kritik" prosedürleri test etmek, diğerlerini atlamak mümkün mü? En iyi yaklaşım, mümkün olduğunca çok sayıda fonksiyonu kapsamaktır, özellikle gelecekte kod birkaç ekip tarafından değiştirilecekse: belirsiz hesaplamalar ve sınır durumları genellikle standart olmayan dallarda ortaya çıkar.

Yaygın hatalar ve anti-desinler

Setup/teardown olmaması → testler birbirlerini etkiler
Sadece "pozitif" senaryoların kapsanması, olumsuz testlerin eksikliği
Test verilerinin karmaşık/istenmeyen bir yapısı

Hayattan bir örnek

Olumsuz durum

İndirim hesaplama prosedürünü geliştirdikten sonra birkaç durum manuel olarak test edildi, ana mantık dalları gözden kaçtı. Üretimde müşteriler hatalı indirimler almaya başladı, durumu anlamak birkaç gün sürdü.

Artılar:
Başlangıçta zaman kazancı.

Eksiler:
Manuel düzeltmelerde kayıplar, geliştirme ve yeniden yapılandırma sırasında zorluk.

Olumlu durum

Anahtar UDF'ler ve prosedürler için pgTAP ile birim testleri geliştirdik, entegrasyon testleri her dalın birleştirilmesinde CI üzerinden çalıştırılmaktadır. Hatalar ve regresyonlar, dağıtımdan önce belirlenmektedir.

Artılar:
Fonksiyonların istikrarı, iş mantığını hızlı bir şekilde geliştirme imkanı, üretimde minimum hatalar.

Eksiler:
Test tabanını başlatmak ve desteklemek için zaman yatırımı gerekmektedir.