Frontend Unit Testi
Javascript çok önceden icat edildi. Başlangıçta küçük tarayıcı içi etkileşimler için kullanıldı. Son 10 yılda javascript büyük bir evrim geçirdi. Bu evrim geçirmede ki en büyük rol sahipleri SPA’lar (tek sayfa uygulamalar) ve NPM paket yöneticisidir. Bu gelişmeler Javascript’e süper güçler verdi. Bu gelişmeler ile birlikte kod tabanı daha büyük ve daha karmaşık hale gelmeye başladı. Daha büyük bir kod tabanı, hatalara karşı daha savunmasızdır. Bu yazımızda nasıl hatalara dayanıklı bir kod tabanı yapılacağını göreceğiz.
Unit (Birim) Testi Nedir?
Birimlerin ne olduğu hakkında ayrıntılara girmeyeceğiz. Kısaca söylemek gerekirse, yazılım mühendisliği best practices(en iyi yöntem), kodu küçük bileşenlere veya modüllere ayırmayı önerir. Bu tür bir ayırma, kodun sürdürülebilirliğini ve okunabilirliğini artıracaktır.
Konumuza dönelim. Birim testleri, yeni değişiklikler yapılırken kodumuzun doğru şekilde çalışmasını sağlamaktan sorumludur. Belirli fonksiyonlar veya componentler küçük etkileşimlerdir. Bu etkileşimlerin bir sonucu olarak, birim testleri, components/fonksiyondan belirli yanıtlar almayı bekler. En azından bir uygulamanın temel işlevleri test edilmelidir.
Basitleştirmek için gerçek hayattan bir örnek kullanalım. İçinde altı yumurta bulunduran bir kutu satın almak istiyorsunuz. Neyi kontrol etmelisiniz?
- Bir kutu yumurta mı yoksa başka bir şey mi?
- Hiç yumurta var mı?
- Altı veya daha az yumurta var mı?
- Kırık yumurta var mı?
- İstediğin boyuttalar mı?
Unit Testleri Yazmazsam Ne Olur?
Hiçbir şey olmaz. En azından ilk bakışta. Ancak kod tabanınız büyüdükçe, onu korumak ve hata ayıklamak zorlaşır. Bazen bir hata karşılaşıp göz ardı edebilirsiniz. Haftalarca süren geliştirmeden sonra hata tekrardan çıkar ve uygulamayı çökertir. Paniklemeye ve kodunuzun her bir parçasında hata ayıklamaya başlarsınız. Hata ayıklamak için saatler hatta günler harcadıktan sonra, sorunun küçük bir hatada olduğunu anlarsınız.
Ya biri size bu durumdan kaçınabileceğinizi söyleseydi? Ya da en azından hata sayısını azaltabileceğinizi. Çözümlerden biri Unit testleridir.
Evet, bazen herhangi bir teste ihtiyacınız olmadığı durumlar vardır. Örneğin, asla canlı (production) ortama geçmeyecek bir prototip geliştiriyorsunuz. Burada amaç, istikrarlı bir uygulama geliştirmek değil, bir kavram bir konsept geliştirmektir.
Nasıl Çalışırlar?
Modern javascript ortamında, geliştiriciler için testi kolaylaştıran çeşitli kütüphaneler (libraries) vardır. En popüler olanlardan bazıları Jest, Jasmine. Built-in yöntemlere sahiptirler. Ana kısmı “expect” methodudur. method/component leri beklediğiniz çıktıyı verip vermediğini kontrol eder.
Örneğin jasmine ele alalım.
describe("A suite is just a function", ()=> {
let a; it("and so is a spec", ()=> {
a = true; expect(a).toBe(true);
});
});
Ne Zaman Yazmalı?
Unit testlerinde çeşitli yaklaşımlar vardır. Her geliştiricinin testle ilgili kendi tercihleri vardır. Ayrıca, her şirketin yazılımı test etmek için kendi yönergeleri ve gereksinimleri vardır.
TDD yaklaşımı, önceden testler yazmayı ve ardından kodu yazmayı önerir. Bununla birlikte, hemen hemen her şey zaten teknik genel bakışta açıklandığında, bu yaklaşım sistematik yazılım geliştirmeye uyar. Çoğu durumda, sürece göre çözümler seçer ve yöntemler yazarsınız. Bu, testlerden önce yazılan yöntemler anlamına gelir.
Bu durumda bile, adım adım testler yazmanızı şiddetle tavsiye ederim. Bir metot yazdınız ve arkasında birim testlerini yazınız. Aksi takdirde, birçok yöntem veya bağımlılık içeren uzun bir kodla karşılaşırsınız. Ve test etmeye başladığınızda şiddetli bir baş ağrısına dönüşebilir.
Mock (Sahte) Data
Birim testlerinin amacı, sınıf, component, fonksiyon gibi belirli birimleri kontrol etmektir. Bu, ilgili olmayan tüm kodları yok saymanız gerektiği anlamına gelir. Yine de birçok component’in üçüncü taraf kitaplıklarına veya diğer bileşenlere dış bağımlılıkları vardır. Bu durumda, unit testi içinde bu bağımlılıkları ve durumları simüle edecek statik kodla değiştirmemiz gerekir.
Jasmine, verileri simüle(mocking) etmek için yerleşik yöntemlere sahiptir. Örneğin createSpyObj veya spyOn gibi.
Test Kapsamı
Testleri her oluşturduğunuzda, gerçekten ihtiyacınız olanı test ettiklerinden emin olun. Testin geçtiği ve yeşil olduğu birçok durum vardır, ancak gerçekte hiçbir şeyi kontrol etmediği veya yanlış ifadeyi kontrol etmediği durumlarda olabilir.
Başka bir hata, beklentileri teste tabi tutmamak olabilir. Test kapsamına dikkat edin. Case’lerin tamamının veya çoğunun test kapsamında olup olmadığını kontrol etmeniz gerekir.
Sonuç
Unit testlerinin temel amacı, geliştirme ekipleri için stabil çalışma sağlamaktır.
Tekrar özetleyelim:
- Tüm olası case senaryolarını test edin.
- Kod kapsamı(coverage) seviyesini kontrol edin.
- Herhangi bir harici sınıf/servisi simüle(mocking) edin.
- Üçüncü taraf(third-party) kütüphaneleri test etmeyin.
- Geliştirmede ilerlediğiniz anda testler yazın. Sonuna kadar beklemeyin
