Test Verisi Yönetimi

Blog

Gerçek Veritabanlarıyla Test: Mock’lar Neden Yanıltır, Güçlü Ekipler Nasıl Test Eder?

Unit test mock’larının ve bellek içi veritabanlarının üretim hatalarını neden kaçırdığını, gerçek HTTP-veritabanı entegrasyon testlerini ve Subsetra Ark’ın güvenli geçici test veritabanlarını nasıl sunduğunu keşfedin.

Subsetra Ark Ekibi 7 dk okuma

Bir mühendislik ekibine veritabanı test stratejisini sorun; tanıdık bir hikâye duyarsınız: CI’daki bütün unit test’ler yeşildir, fakat pull request staging’e veya üretime ulaştığı anda uygulama beklenmedik bir veritabanı hatasıyla çöker:

ERROR: column "tenant_id" of relation "orders" does not exist
-- veya --
ERROR: invalid input syntax for type jsonb: "undefined"

Yüzlerce başarılı unit test’in arkasındaki kod üretimde nasıl bozulabilir?

Cevap temel bir mühendislik takasında yatar: hız ve doğruluk. Ekipler yıllarca CI build’lerini hızlı tutmak için mock, stub veya SQLite gibi hafif bellek içi veritabanlarına güvendi. Bunu yaparken gerçek veritabanı engine’ini test etmeyi bıraktı; kritik SQL sorguları, ORM entity eşlemeleri, foreign key cascade’leri ve şema migration’ları deployment’a kadar doğrulanmadı.

Bu yazı güncel veritabanı test yöntemlerini, gerçek ve tek kullanımlık veritabanına HTTP istekleri göndermenin kabul görmüş bir sektör modeli olup olmadığını, geleneksel mock’ların neden yetersiz kaldığını ve kapsamlı Test Data Management platformu Subsetra Ark’ın referans bütünlüğü korunmuş geçici veritabanlarını nasıl sunduğunu ele alıyor.

1. Güçlü mühendislik ekipleri veritabanı destekli uygulamaları nasıl test eder?

Veri yoğun uygulamalar ve mikroservisler için modern ekipler dört temel test modelini birlikte kullanır:

+---------------------------------------------------+
|  1. E2E ve Entegrasyon Testi                      |
|     (Gerçek Geçici DB + HTTP API)                |
+---------------------------------------------------+
|  2. Contract Testi (Pact / OpenAPI)              |
+---------------------------------------------------+
|  3. Bellek İçi Veritabanı (SQLite / Embedded DB) |
+---------------------------------------------------+
|  4. Mock / Stub ile Unit Test                    |
+---------------------------------------------------+

Yaklaşım A: Mock ve stub ile unit test

  • Nasıl çalışır? Veritabanı repository’si veya ORM arayüzü jest.fn(), vi.fn() ya da Mockito gibi araçlarla taklit edilir. Controller veya servis metodu çalıştığında SQL üretilmez; önceden tanımlanmış JavaScript nesnesi ya da entity hemen döner.

  • Kod örneği:

    const mockUserRepository = {
    findOne: vi.fn().mockResolvedValue({ id: 'usr_123', email: 'user@example.com' }),
    save: vi.fn().mockResolvedValue({ id: 'usr_123', status: 'ACTIVE' })
};

  • En uygun alan: Veritabanı mantığı içermeyen saf hesaplamalar, doğrulama kuralları, state machine’ler ve DTO dönüştürücüleri.

Yaklaşım B: Bellek içi veritabanı testi

  • Nasıl çalışır? Uygulama test sırasında repository’yi mock’lamak yerine SQLite veya H2 gibi hafif, bellek içi engine’e bağlanır. Tablolar RAM’de sıfırdan oluşturulur ve Docker ya da dış servis olmadan gerçek SQL çalıştırılır.
  • En uygun alan: Yalnızca standart SQL kullanılan, PostgreSQL JSONB veya pgvector gibi sağlayıcıya özgü özelliklere ihtiyaç duymayan hafif prototipler.

Yaklaşım C: Contract testi

  • Nasıl çalışır? Pact gibi araçlar downstream servislerin HTTP/gRPC payload’larını, header’larını ve status code’larını contract dosyaları üzerinden upstream sağlayıcıya karşı doğrular.
  • En uygun alan: Bütün servis topolojisini ayağa kaldırmadan mikroservis sınırlarını doğrulamak.

Yaklaşım D: Gerçek geçici veritabanı ve HTTP entegrasyon testi

  • Sektörde kabul görmüş gerçek bir model mi? Evet.
  • Terimler: Ephemeral Integration Testing, Component Testing, Testcontainers Pattern ve Ephemeral Test Environments.
  • Nasıl çalışır? CI pipeline’ı veya test paketi Docker içinde gerçek PostgreSQL ya da MySQL instance’ı ve uygulamanın gerçek HTTP servisini başlatır. Testler Supertest, Playwright API veya RestAssured ile gerçek HTTP/gRPC istekleri gönderir. Uygulama isteği işler, gerçek engine’e SQL çalıştırır ve gerçek response döndürür. Test bitince veritabanı ile uygulama container’ı tamamen yok edilir.

2. Test stratejilerinin karşılaştırması

Değerlendirme Gerçek geçici DB (Docker / Ark) Unit mock / stub Bellek içi DB Paylaşılan staging Tam üretim dump’ı
Üretim doğruluğu ⭐⭐⭐⭐⭐ Gerçek engine ⭐⭐ Çok düşük ⭐⭐⭐ Orta ⭐⭐⭐⭐ Yüksek ⭐⭐⭐⭐⭐ Tam
SQL ve ORM dialect doğrulaması ⭐⭐⭐⭐⭐ Tam ❌ Yok ⭐⭐ Dialect farkı ⭐⭐⭐⭐⭐ Tam ⭐⭐⭐⭐⭐ Tam
Şema migration güvenliği ⭐⭐⭐⭐⭐ Kırıcı değişikliği yakalar ❌ Yok ⭐⭐ Sınırlı ⭐⭐⭐ Kirli durum ⭐⭐⭐⭐ Yavaş
Test hızı ⭐⭐⭐⭐ Ark ile saniyeler ⭐⭐⭐⭐⭐ Milisaniye ⭐⭐⭐⭐ Saniye ⭐⭐⭐⭐ DSN hazır ❌ Yükleme saatler sürer
Ortam yalıtımı ⭐⭐⭐⭐⭐ Tamamen geçici ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ❌ Ekip çakışması ⭐⭐⭐⭐⭐
Veri güvenliği ve PII ⭐⭐⭐⭐⭐ VPC içinde maskeli ⭐⭐⭐⭐⭐ Sentetik ⭐⭐⭐⭐⭐ Sentetik ❌ Maskelenmemiş PII ❌ Kritik PII riski

3. Yalnızca gerçek veritabanı testinin yakalayabildiği hatalar

Mock ve bellek içi veritabanları üretimi neden koruyamaz? Üç yaygın hata unit test’lerden kolayca geçer, gerçek engine’de ise bozulur.

1. Veritabanına özgü SQL dialect ve fonksiyonları

Modern uygulamalar engine’e özgü özellikleri yoğun kullanır:

  • PostgreSQL JSONB path sorguları (jsonb_set, ->>) ve array operatörleri (@>)
  • MySQL JSON_CONTAINS() ve spatial fonksiyonları
  • window fonksiyonları, advisory lock ve satır kilitleme (SELECT ... FOR UPDATE)

SQLite veya JavaScript mock’u sağlayıcı SQL engine’ini çalıştırmaz. JSONB fonksiyonu kullanan bir sorgu mock testinden sorunsuz geçer; JSON anahtar yapısı veya SQL syntax’ı hatalıysa gerçek PostgreSQL’de anında çöker.

2. Entity ile şema kolonu uyumsuzluğu

Geliştirici TypeORM, Prisma veya Hibernate modeline @Column() eklediğinde unit mock, test dosyasındaki hardcoded nesneyi döndürmeye devam eder.

Migration oluşturulmadı veya çalıştırılmadıysa unit test yine geçer. Gerçek veritabanı testi ise gerçek tabloya insert denediği anda ER_BAD_FIELD_ERROR: Unknown column hatasını main branch’e ulaşmadan üretir.

3. Karmaşık ORM ilişkileri ve transaction davranışı

ORM’ler gizli çalışma zamanı davranışlarıyla bilinir:

  • N+1 sorgu problemi: Lazy-loaded ilişkiler üretimde yüzlerce sorgu çalıştırırken mock hazır array döndürür.
  • Döngüsel ilişki ve cascade delete: ON DELETE CASCADE foreign key kuralları sessizce başarısız olabilir veya constraint violation üretebilir.
  • Transaction rollback: Çok tablolu işlemler içinde beklenmeyen hata olduğunda bütün değişikliklerin geri alındığı doğrulanmalıdır.

4. Gerçek veritabanı testi darboğazı ve Ark’ın çözümü

Gerçek, tek kullanımlık veritabanıyla test altın standartsa neden her şirket bunu her pull request için kullanmıyor?

Tarihsel olarak üç darboğaz vardı:

  1. Hazırlama süresi: 300 GB üretim dump’ını Docker’a restore etmek saatler sürer; geliştirici hızını ve CI kapasitesini düşürür.
  2. PII ve gizlilik ihlali: Üretim verisini CI runner’a veya geliştirici ortamına restore etmek ciddi GDPR, KVKK ve CCPA riski taşır.
  3. Kirli staging çakışması: Kalıcı staging’i paylaşmak flaky test, şema drift’i ve veri bozulması üretir.

Geçici ortam duvarı: Hosting platformları neden veritabanı katmanında durur?

Modern preview platformları stateless web container’larını saniyeler içinde başlatabilir. Veritabanı katmanında ise sert bir duvara çarpar:

  • Seed script tuzağı: Boş veritabanını basit seed dosyalarıyla doldurmak gerçek join’lerin, edge case’lerin ve veri biçimlerinin çoğunu kaçırır.
  • Tam snapshot tuzağı: Her CI çalışmasında tam üretim backup’ı restore etmek 30–60 dakika sürer ve cloud depolama maliyetini katlar.
  • Uyumluluk riski: Ham üretim backup’ını test ortamına taşımak hassas müşteri verisini açığa çıkarır.

Subsetra Ark’ın getirdiği temel ilerleme budur:

  • Mühendislik hızı: CI veritabanı hazırlığını onlarca dakikadan saniyelere indirir.
  • Daha düşük altyapı maliyeti: Terabaytlık klonların yerine referans bütünlüğü korunmuş küçük alt kümeler kullanır; test depolama ve ağ maliyetini azaltır.
  • Zero-trust gizlilik: PII verisini test container’ına ulaşmadan önce VPC sınırı içinde keşfeder ve maskeler.

CI içinde Subsetra Ark

Subsetra Ark; otomatik PII keşfi, VPC-içi statik maskeleme, referans grafiği alt kümeleme, federated sentetik veri üretimi ve sürekli şema drift tespiti sunan kapsamlı bir Test Data Management platformudur.

Geçici, tek kullanımlık ve üretime benzer veritabanlarını CI/CD ile geliştirici iş akışlarına sunmak platformun en güçlü kullanım alanlarından biridir.

[ Üretim DB (Terabaytlar) ]
              │
              ▼
┌───────────────────────────────────────────┐
│ Ark Agent (VPC İçi Yürütme)               │
│ • Graf farkındalıklı referans alt kümesi  │
│ • Otomatik PII keşfi ve maskeleme         │
└───────────────────────────────────────────┘
              │
              ▼  (ark-cli testenvs create --wait)
┌───────────────────────────────────────────┐
│ Geçici Docker Test DB                     │
│ • Küçük, yalıtılmış container             │
│ • Maskeli ve referans bütünlüklü          │
└───────────────────────────────────────────┘

1. Graf farkındalıklı referans alt kümeleme

Ark’ın ilişkisel graf engine’i hedef başlangıç varlıklarından — örneğin 200 temsili müşteri hesabı — başlayarak veritabanı topolojisini izler. Karmaşık foreign key ağaçlarında referans bütünlüğünü koruyarak ilgili siparişleri, işlemleri, ürünleri ve audit loglarını çıkarır. Yüzlerce GB’lık veritabanı saniyeler içinde küçük bir veri dilimine dönüşür.

2. VPC-içi otomatik PII keşfi ve maskeleme

Veri test container’ına ulaşmadan önce ark-agent, müşteri VPC’sinde ad, e-posta, kredi kartı numarası, destek notu ve JSON payload gibi PII verilerini bulur. Üretim gerçekliğini korurken gerçek müşteri verisini açığa çıkarmayan deterministik ve format koruyan kurallar uygular.

3. Anında geçici hazırlama

Her test çalışması için tek kullanımlık veritabanı tek CLI komutuyla oluşturulur:

# 30 dakika TTL'li, maskelenmiş PostgreSQL test veritabanı başlatın
ark-cli testenvs create \
  --dataset e-commerce-subset \
  --db-type postgres \
  --ttl 30m \
  --wait

Ark altyapınızın içinde yalıtılmış Docker veritabanı hazırlar, migration’ları uygular, referans bütünlüklü veri kümesini yükler ve temiz DSN döndürür. Test veya TTL bittiğinde container otomatik kaldırılır.

4. Şema drift tespiti ve yeniden sınıflandırma

Üretim şemaları sürekli değişir. Ark yeni kolonları, değişen tipleri ve silinen tabloları algılar; sınıflandırma ile maskeleme güncellemelerini tetikler. Entegrasyon ortamları şema drift’i nedeniyle sessizce eskimez.

5. İdeal test mimarisi: Modern test piramidi

Ekipler build hızından vazgeçmeden güvenilirliği artırmak için test piramidini stratejik kurmalıdır:

                             /\
                            /  \      E2E ve Geçici DB Testleri
                           /    \     -> HTTP API, SQL, ORM eşleme,
                          /  I   \       migration ve FK cascade
                         /--------\
                        /          \  Unit Test (Mock / Stub)
                       /     U      \ -> Saf iş mantığı, DTO doğrulama,
                      /--------------\   hesaplama ve state machine
  1. Unit test’ler: Mock ve stub’ları yalnızca veritabanı etkileşimi olmayan, bellek içi domain mantığı, DTO formatlama ve matematiksel hesaplamalarda kullanın.
  2. Geçici DB entegrasyon testleri: Her test paketi veya pull request için Subsetra Ark ile gerçek PostgreSQL/MySQL veritabanı başlatın. Uygulama servisini ayağa kaldırın, gerçek HTTP/gRPC isteği gönderin ve uçtan uca veri değişikliklerini gerçek engine üzerinde doğrulayın.

Sonuç

Veritabanı çağrılarını mock’lamak tehlikeli bir güven hissi yaratır. Unit test’ler domain mantığı için vazgeçilmezdir; ancak SQL dialect hatalarını, bozuk ORM eşlemelerini, eksik migration’ları ve transaction sorunlarını yalnızca gerçek veritabanı entegrasyon testleri yakalayabilir.

Subsetra Ark ile ekipler tam veritabanı klonlarını saatlerce beklemek veya güvenilmez mock’larla üretim hatası riskini almak arasında seçim yapmak zorunda kalmaz. Graf farkındalıklı alt kümeleme, VPC-içi otomatik PII maskeleme ve ark-cli ile anında geçici hazırlama sayesinde gerçek ve üretime benzer veritabanları üzerinde saniyeler içinde test çalıştırılabilir.

Test pipeline’ınızı dönüştürmek için Subsetra Ark dokümantasyonunu inceleyin veya demo planlayın.