Snapshot testi, bir bileşenin çıktısını ilk koşuda dosyaya yazar, sonraki koşulda aynı dosyayla karşılaştırır. Fark varsa test kırılır. Basit, hızlı, cazip. Ama aynı cazip, ekibin "güncelle" tuşuna basma alışkanlığına dönüşebilir; o andan sonra snapshot testi artık test değil, dosya saklama alışkanlığıdır. Bu yazının konusu, yöntemin kendisi değil, yanlış kullanıldığında verdiği yanlış güven: yeşil ışığın ne zaman bir aldatmacaya dönüştüğünü tanımak.

Ne işe yarar, neyi korumaz?

Snapshot en iyi, bileşenin sözleşmesinin kaydı olarak çalışır: "bu çıktı kasıtlıydı, değişirse haber ver." Özellikle küçük, sunum odaklı bileşenlerde — etiket, rozet, tarih biçimleyici — kırılganlığı düşük, maliyeti sıfıra yakın bir güven ağı kurar. Snapshot testinin psikolojik faydası da vardır: geliştirici, farkı onaylamak için çıktıyı satır satır okumak zorunda kalır. Bu zorunlu bakış, yöntemin asıl değeridir. Snapshot, bileşenin doğruluğunu değil yalnızca değişmezliğini doğrular.

it("tarih rozeti biçimi", () => {
  const { container } = render(Rozet({ tarih: "2026-05-06" }));
  expect(container.firstChild).toMatchSnapshot();
});

Sorun, snapshot'ın neyi korumadığını anlamamaktan doğar. Snapshot, bileşenin doğruluğunu değil yalnızca değişmezliğini doğrular. İlk kez yazıldığı andaki hataları da kaydeder ve onları korumaya alır. Bu yüzden snapshot'ın olduğu yerde mutlaka davranışa odaklı testlerin de bulunması gerekir; snapshot tek başına güven ağı değil, ağını bir karesidir. Kaydı hangi gün, hangi geliştirici, hangi koda bakarak aldığı da kayıtlıdır: iki yıl önceki bir aceleyle üretilmiş çıktı, iki yıl boyunca doğruluk gibi korunabilir.

Kırmızı bayraklar

İlk uyarı ışığı, güncelleme döngüsüdür. Ekip, -u bayrağını alışkanlıkla basıyorsa snapshot'lar denetlenmiyor demektir. İkinci ışık, dev snapshot dosyalarıdır: yüzlerce satırlık bir çıktıyı kim okuyor? Üçüncüsü, saat, rastgele kimlik veya ağa bağlı veriler içeren snapshot'lar; bunlar çalıştırmaya göre değişir ve "geçici kusur" üretir. Dördüncüsü daha az görünürdür: her PR'da onlarca snapshot farkı düşüyorsa, snapshot'lar artık değişimin gürültüsüne katılmıştır; ekip farkı okumayı bırakır, okunmayan fark ise güvenlik değildir.

// Kırılgan snapshot yerine gerekli kısmı seçin
expect(
  within(container).getByRole("status").textContent
).toMatchInlineSnapshot("3 yorum onay bekliyor");

Sağlıklı kullanım

Snapshot'ı büyük resim için değil, sözleşmenin hassas yerleri için kullanın: tarih biçimi, para birimi, aria öznitelikleri, sınıf adları. Çıktının tamamını değil, değişmesi durumunda gerçekten acı çekeceğiniz kısmı kaydedin. Zaman ve rastgelelik sahte sabitleyicilerle (sahte saat, sabit seed) denetim altına alınmalı; aksi hâlde snapshot her koşuda farklı bir şey görmek ister.

Bir de ekip disiplini gerekir: snapshot farkı çıktığında ilk bakış kodda değil, fark çıktısında olmalıdır. Fark iki satırlık bir düzeltme mi, yoksa bileşenin davranışını değiştiren beklenmedik bir eğilim mi? Snapshot bu soruyu sorar; cevabı ekibe vermek düşer. İncelemede farkı okuyan kişi, farkı yazan kişi olmalıdır; "güncelledim, geçti" cümlesi inceleme notlarına girmemelidir. Aksi taktirde snapshot dosyası, hiç kimsenin okumadığı bir kayıt defterine dönüşür.

Son söz: snapshot bir kısayoldur, kısayol da yalnızca doğru yerde kullanıldığında kısaltır. Uyarı ışığı yandığında tuşa değil, çıktıya bakın.