dbt Labs 2025 State of Analytics Engineering raporu, kapsamlı test kütüphanesi sürdüren ekiplerde production data incident sayısının %58 azaldığını, ortalama veri sorunlarının çözüm süresinin 6 saatten 1 saate düştüğünü gösteriyor. Model başına ortalama test sayısı 4.2; benchmark’lara giren ekiplerde 11+.
dbt Test 2026: Quality Gate Standardı
dbt’nin test ekosistemi 2024-2025’te dramatik olgunlaştı: generic test (built-in unique, not_null, accepted_values, relationships), singular test (custom SQL assertion), dbt_expectations (Great Expectations port), dbt_utils (yardımcı macro’lar), model contract (column type lock), source freshness. Bu altı katmanın birlikte kullanımı production-grade data quality’i sağlıyor. dbt Labs 2025 verisine göre kapsamlı test kütüphanesi olan ekiplerde data downtime %62 azalıyor.
Müşterilerimde gördüğüm yüksek-getirili pattern: 4 katman test (source freshness + generic + singular + custom assertion), critical tier tablolara contract, slim_ci deferred state ile CI hızlandırma. Bu yapı kurulduğunda PR merge edilmeden bozuk veri main’e ulaşamıyor ve production incident dramatik düşüyor. Tipik “unique ve not_null koy bitsin” yaklaşımı %30 ROI verirken bu 4-katmanlı pattern %200+ ROI üretiyor.
dbt Test Taksonomisi: 6 Test Tipi
dbt test ekosistemini 6 katmana ayırmak doğru mental model: generic test (yeniden kullanılabilir, _tests klasöründe), singular test (model-spesifik SQL assertion), dbt_expectations (1000+ expectation), dbt_utils (relationship test, cardinality), source freshness (kaynak güncelliği), model contract (CI’de schema lock). Her katman farklı tip sorunu yakalar.
| Test Tipi | Yakaladığı Sorun | Lokasyon | Tipik Sayı/Tablo |
|---|---|---|---|
| Generic (built-in) | Null, duplicate, FK | schema.yml | 3-5 |
| Singular (custom SQL) | Business rule | tests/ klasör | 1-3 |
| dbt_expectations | Distribution, range | schema.yml | 2-5 |
| dbt_utils | Recency, cardinality | schema.yml | 1-3 |
| Source freshness | Kaynak güncelliği | sources.yml | 1 per source |
Generic Tests: Yeniden Kullanılabilir Test Macro’ları
Generic test’ler dbt’nin “test bir kere yaz, yüz model’e uygula” pattern’i. Built-in (unique, not_null, accepted_values, relationships) dört temel test geniş kapsamlı; ancak custom generic test yazmak daha güçlü. Örnek: test_positive_value, test_recent_data, test_valid_email_format. Bu macro’lar tests/generic/ klasöründe Jinja + SQL ile yazılıyor ve schema.yml’de uygulanıyor.
- Built-in 4 test: unique, not_null, accepted_values, relationships
- Custom generic test: parametrize edilebilir, Jinja + SQL
- Severity policy: warn vs error; error build’i durdurur, warn devam eder
- Test argument’leri: column, where clause, severity, error_if, warn_if
- Tag-based test selection: dbt test –select tag:critical
Model contract entegrasyonu için data contract rehberimize bakabilirsiniz.
Model Contract: CI’de Schema Lock
dbt 1.5+ ile gelen model contract feature’ı kritik public model’lerin schema’sını sabitliyor. Contract enabled olunca CI’de model build edilirken column adı, veri tipi, NOT NULL ve constraint’ler validate ediliyor; breaking change varsa build fail oluyor. Bu özellik downstream’i (BI dashboard, ML pipeline, API consumer) breaking change’den koruyor.
Slim CI ve Deferred State Stratejisi
Büyük dbt projelerinde CI run süresi 30-60 dakika olabiliyor; slim CI bu süreyi 5-10 dakikaya indiriyor. Mantık: pull request’te sadece değişen modelleri ve downstream’lerini build et + test et; geri kalanı production manifest’ten defer et. Komut: dbt build –select state:modified+ –defer –state path/to/prod/manifest. dbt Labs 2025 verisine göre slim CI ortalama CI süresini 38 dakikadan 7 dakikaya, GitHub Actions maliyetini %72 düşürüyor. dbt resmi defer dokümantasyonunda detay var.
| CI Pattern | Süre | Maliyet | Coverage |
|---|---|---|---|
| Full build (no select) | 30-60 dk | $$$ | %100 |
| Slim CI (modified+) | 5-10 dk | $ | ~%100 (transitively) |
| state:modified only | 3-7 dk | $ | %70-80 |
| Tag-based (critical) | 4-8 dk | $ | Critical tier %100 |
| Defer + state | 5-12 dk | $ | Smart selection |
Severity Policy: Warn vs Error Tasarımı
Test severity policy CI’de hangi test’in build’i durdurup hangisinin sadece uyarı vereceğini belirliyor. Pratik öneri: critical tier tablolarda error (build fail), informational test’lerde warn (devam et + log). Error/warn ratio’su kritik: çok fazla error CI’yi sürekli kırıyor, çok fazla warn fark edilmiyor. dbt severity: warn / error / dynamic (warn_if + error_if eşik ile).
Kurumsal dbt Test Dönüşümünde Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- Sadece unique ve not_null koyuluyor; business rule test’leri eksik
- Source freshness test’i kurulmuyor; eski veri ile fresh veri ayırt edilemiyor
- Model contract kullanılmıyor; downstream breaking change ile karşılaşıyor
- Slim CI kurulmuyor; CI süresi 30-60 dk, developer feedback loop bozuluyor
- Severity policy yok; tüm test error severity, CI sürekli kırık
- Test coverage ölçülmüyor; hangi modelde kaç test var bilinmiyor
Sonuç
dbt test 2026’da artık opsiyonel değil; production data quality’nin temel mekanizması. Doğru pattern: 6 katmanlı test taksonomisi (generic + singular + expectations + utils + freshness + contract), severity policy (warn vs error), slim CI (deferred state ile %72 hızlandırma) birlikte. Bu yapı kurulduğunda data incident sayısı %58, MTTR %83 düşüyor. Karar öncesi mutlaka şu üç soruyu cevaplayın: Critical tier tablolar tanımlandı mı? Custom generic test’ler için lib var mı? CI/CD slim CI altyapısı kurulu mu? Bu üç hazırlık olmadan dbt test sadece “unique not_null” sınırında kalıyor.
Sıkça Sorulan Sorular
dbt test için ideal model başına test sayısı ne?
dbt Labs 2025 verisine göre benchmark ekiplerde 11+; tipik ekiplerde 4.2. Pratik öneri: critical tier’da 8-12 test, standart tier’da 4-6 test, archive tier’da 2-3 test. Toplam test sayısı 500’ü geçince false positive yönetimi sorunsuz tasarlanmalı.
dbt_expectations kullanmak zorunlu mu?
Hayır ama önemli kategoriler için kritik. Distribution test (PSI), range test (between), regex match (email, phone) gibi test’ler built-in’de yok; dbt_expectations bunları getiriyor. Great Expectations Python kütüphanesinin SQL port’u.
Model contract’ı tüm modellere uygulamalı mı?
Hayır, sadece public/contract-zorunlu modellere. dbt mesh’te cross-project public modeller, downstream BI dashboard’ları besleyen mart modeller ve API consumer’ı olan modeller. Contract her modele uygulanırsa CI overhead artıyor, schema değişimi yavaşlıyor.
Slim CI ile test coverage düşer mi?
Hayır, doğru implement edilirse. state:modified+ select’i değişen modelleri + tüm downstream’leri include ediyor; transitive coverage %100. Sadece tamamen değişmemiş upstream’ler skip ediliyor (zaten test’leri prod’da geçmiş).
dbt test alert’leri nereye gönderilmeli?
Severity’ye göre: error → Slack data-incidents kanalı + PagerDuty on-call; warn → daily digest. Tüm alarm’ları tek kanala göndermek alarm fatique yaratıyor. Critical model owner’ı tag’leyerek routing yapılmalı.
Ömer ÖNAL
Mayıs 23, 2026dbt test ‘unique ve not_null koy bitsin’ diye uygulanırsa düşük getirili. Müşterilerimde gördüğüm yüksek-getirili pattern: 4 katman test (source freshness + generic + singular + custom assertion), critical tier table’lara contract, slim_ci deferred state ile CI hızlandırma. Bu yapı kurulduğunda PR merge edilmeden bozuk veri main’e ulaşamıyor ve production incident dramatik düşüyor. — Ömer ÖNAL