Snapshot Testi Nedir, Ne Değildir?

Tuğsan Ünlü
Akbank Teknoloji
Published in
4 min readFeb 2, 2024

--

Nedir?

Geliştirdiğimiz uygulamaların veya uygulama parçalarının, beklediğimiz şekilde çalıştığından emin olmak ve bunun sürekliliğini sağlamak için ihtiyaca yönelik olarak birim testler, entegrasyon testleri veya uçtan uca testler yazıyoruz. Bu testler çoğu zaman bir fonksiyonun veya akışın, aynı girdilerle çalıştırıldığında aynı çıktıları vermesini, yani deterministik olmasını amaçlıyorlar. Fakat kimi zaman da girdilerle çok fazla uğraşmadan, elimizdeki çıktıları, daha önce aldığımız çıktılarla karşılaştırmak ve buradan bir sonuca varmak da pratik bir çözüm olabiliyor. Bu saikle yapılan testlere snapshot test ismi veriliyor.

Örnek

Bir web uygulamasının sayfa başlıklarında kullandığımız çok basit bir React component’i olduğunu düşünelim elimizde. Bu component birkaç stile sahip olsun ve dışarıdan bir başlık metni alsın.

title.jsx

Bu component içerisinde yazılan JSX kodu, render olduğunda aşağıdaki gibi bir HTML çıktı elde edeceğiz.

title.jsx render

Component içerisinde, component’in çıktısını değiştirebilecek bir kondisyon olmadığını bildiğimiz için, bu component’in aynı girdilerle her render edildiğinde aynı HTML çıktıyı vereceğinden eminiz. Bu sayede her defasında component’e dışarıdan doğru şekilde prop geçebiliyor muyuz, geçtiğimiz prop, istediğimiz şekilde son kullanıcıya gösteriliyor mu gibi testleri daha pratik bir şekilde yapabiliyoruz.

JavaScript ekosisteminde kullandığımız test runner aracı Jest, snapshot testler için oldukça basit bir API sunuyor. Jest, aşağıdaki test dosyası çalıştırıldığında Title component’i için daha önce alınmış bir snapshot dosyası varsa eğer component’in güncel çıktısı ile o dosyayı karşılaştırıyor. Eğer yoksa sonraki testlerde kullanılmak üzere .snap uzantılı yeni bir snapshot dosyası oluşturuyor.

title.test.js
title.test.js.snap

Oluşturulan snapshot dosyaları, test senaryolarında ortaya attığımız assertion’lar (iddialar) yerine geçiyor ve zaman kısıtı olan projelerde bizi her durum için yeni bir assertion yazma ihtiyacından kurtarıyor. Yine oluşturulan bu snapshot dosyalarını versiyon kontrol sistemleriyle birlikte repolarımıza dahil ettiğimizde ise CI (Continous Integration) süreçlerinde de snapshot testlerimizi koşturabiliyoruz.

Ne Değildir?

Snapshot testinin ne olmadığına değinmek gerekirse; snapshot testi bir TDD (Test Driven Development / Test Güdümlü Geliştirme) yöntemi değil. Bilindiği üzere TDD pratiklerinde bir kodun ilk olarak testi yazılır ve başarısız olur. Sonrasında yazılan test başarılı olana kadar ilgili kod parçacığı adım adım yazılır. Fakat snapshot testi yazarken doğru çalıştığından emin olduğumuz bir kod parçacığının elimizde olması gerekir. Bu nedenle çalıştırılan ilk snapshot testleri her zaman başarılı olur.

Bir diğer konu, snapshot testleri görsel bir karşılaştırma yapmadığı için çıktılarında oluşabilecek farklılıkları gözle anlamlandırmak gerekebilir. Yukarıdaki aynı component’i ele alalım örneğin. Aşağıdaki her iki kullanım da son kullanıcıya aynı görsel arayüzü verir. Fakat geliştirme esnasındaki tercihlerden dolayı render edilen çıktılarda farklılıklar oluşacaktır. Jest, snapshot testlerinin çalışma prensibi gereği bunun bir hata olduğuna dair alarm verecek ama son kullanıcıya etkisi açısından false positive bir durum oluşturacaktır. Bu durumda ya ilgili kod parçacığının değiştirilmesi ya da sorumluluğun kabul edilerek snapshot dosyasının yeni çıktıyla güncellenmesi gerekecektir.

title-1.jsx
title-2.jsx

Tüm bunlarla birlikte, Jest geliştiricilerinin de üzerinde durduğu gibi snapshot testlerinin, geleneksel birim testlerinin yerini almak gibi iddiası veya misyonu yok. Bilakis, birim testleri destekleyen, tamamlayıcı bir yöntem olarak uygulanıyorlar.

Sonuç

Snapshot testler, özellikle atomik component’lerin testi için oldukça düşük maliyetli ve kullanışlı bir test yöntemi. Fakat component’ler, varoluşlarının aksine birden fazla işi yapmaya başlayarak büyüdüğünde, snapshot testlerinin yönetimi de doğru orantılı olarak güçleşiyor. Snapshot testleri, zaman kısıtı olan projelerde eforsuz bir kurtarıcı olarak, onun dışında kalan diğer tüm projelerde ise mevcut testlerin bir destekçisi olarak kullanmak en doğru pratik olacaktır.

Kaynaklar

--

--