Farklı test türlerine verilen adlar, kod tabanlarında ortak temalara sahip olsa da çok ayrıntılı tanımları yoktur. Bu kursta, her test türünün ne anlama geldiğine dair bazı yönergeler verilmiştir ancak diğer kaynaklar farklı tanımlar sağlayabilir.
Önceki sayfalarda hem birim testleri hem de bileşen testlerine (bizim örneğimizde React bileşenine atıfta bulunan) örnekler verilmiştir. Bunların her ikisini de test piramidimizde (veya başka bir şekilde!) aşağı yerleştirebiliriz. Çünkü karmaşıklık düzeyi düşüktür ve hızla yürütülürler, ancak daha karmaşık bir entegrasyon testi kadar fayda sağlamayabilirler.
Yaygın test türleri
Ünite testleri
Birim testleri, kapsamı en küçük olanlardır. Bunlar, kodun küçük bölümlerini veya tamamen durum bilgisiz kodları neredeyse matematiksel olarak test etmek için kullanılır. Kodunuzu X, Y ve Z girdileri sağlarsam çıktısı A, B ve C olmalıdır.
Birim testleri içeren kodların, normalde bir ağdan getirme ya da dolaylı olarak başka bir işlev veya kitaplık kullanma gibi harici bağımlılıkları olmaz. Kodunuzun "kopyalayıp" kendi başına test edebileceğiniz bir ağaç düğümüdür.
Birim testlerinin yazılıp çalıştırılması genellikle hızlı olsa da küçük kod birimlerini test etmenin faydalı bilgiler sağlamaması her zaman mümkündür. Çoğu zaman bir kod biriminin diğer kodla etkileşim eksikliği, riski azaltmak için daha yüksek bir düzeyde test yapmanızın daha iyi olacağı anlamına gelir.
Bileşen testleri
Web geliştiricileri için "bileşen" adı aşırı yüklenmiştir. Bu ad genellikle React bileşeni veya Web bileşeni gibi kullanıcıların görebileceği bir bileşen anlamına gelir. Daha genel tanımı, test edilebilir bir iş yığınıdır (ör. dış bağımlılıkları olan bir sınıf). Etkili bir şekilde test edilebilmesi için bu bileşenin bağımlılıklarının modellenmiş veya atlanmış olması gerekir.
Modern web geliştirme uygulamaları bileşen kavramına dayandığından bileşen testleri, test üzerine düşünmenin pratik bir yoludur: Örneğin, her bileşenin bir teste ihtiyacı olduğuna karar verebilirsiniz. Bileşen testlerinin takibi, tek bir geliştiricinin veya küçük bir ekibin bir bileşen üzerinde açık sahiplik iddiasında bulunduğu durumlarda kolaydır. Ancak karmaşık bağımlılıkların modelini atmak zor olabilir.
Entegrasyon testleri
Bunlar, doğru çalıştıklarından emin olmak için bileşenlerin, modüllerin, alt sistemlerin veya kodunuzun diğer anlamlı bölümlerinin küçük bir grubunu test etme eğilimindedir. Bu çok muğlak bir tanım. Web geliştiricileri, test ettiğiniz kodun, sitenizin (hatta buna yakın) gerçek bir üretim derlemesi olmadığını, ancak yine de sistemlerinin çeşitli ilgili bileşenlerini birbirine bağladığını düşünün.
Bu, sadece örnek bir örnek yerine test modundaki harici veritabanı gibi "gerçek" bağımlılıkları bile içerebilir. Örneğin, query() işlevinin her zaman aynı iki girişi döndüreceğini söylemek yerine entegrasyon testiniz test veritabanında bir şey olduğunu onaylayabilir. Verilerin kendisi daha az önemlidir ancak şu anda bir veritabanının bağlanıp başarıyla sorgulanabileceğini test ediyorsunuz.
Onaylar kullanılarak kontrol edilebilecek, nispeten basit entegrasyon testleri yazmak mümkündür. Bu testler, onaylamalar kullanılarak kontrol edilebilir. Çünkü çeşitli bileşenlere bağlı tek bir işlem, bir dizi ölçülebilir etkiye neden olabilir.
Bu nedenle, entegrasyon testleri karmaşık sisteminizin amaçlandığı gibi çalışacağını etkili bir şekilde gösterebilir. Ancak yazı yazmak ve sürdürmek zor olabilir ve
gereksiz karmaşıklığa yol açabilir. Örneğin, bir entegrasyon testi için FakeUserService yazmak, hem kendisinin hem de RealUserService öğesinin bir UserService uygulaması şartını ekler.
Duman testleri
Bunlar, çok hızlı bir şekilde tamamlanması ve kod tabanınızın makul bir durumda olup olmadığını belirlemesi gereken testlerdir. Pratikte bu, büyük ölçüde deneyiminiz üzerinde çok çeşitli etkileri olan kod üzerinde basit testler yapmak anlamına gelir.
Örneğin, oturum açılmış büyük bir web uygulamasında bu, giriş ve kimlik doğrulama sisteminin çalıştığından emin olmak olabilir. Çünkü, bu olmadan uygulama kullanılamaz ve ileri düzey testlerle alakasızdır.
Duman testleri, geniş bir kod tabanında package.json dosyanızın test komut dosyasının altında çalışmak için iyi bir aday olabilir. Manuel test de bir tür duman testi işlevi görebilir.
Regresyon testleri
Regresyon testi, yeni bir sürüm veya başka bir özellik geliştirmesinden sonra mevcut özelliklerin çalışmaya devam etmesini ya da eski hataların tekrar sunulmamasını sağlayan bir duman testi türüdür.
Bu, test odaklı geliştirme (TDD) kavramıyla bağlantılıdır. Açıkça bir hatayı tetiklemek için yazılan ve daha sonra hatanın düzeltilmesini sağlamak için kullanılan test durumları, regresyon test durumu olarak sayılır. Çünkü bu durumların, söz konusu hatanın geri dönmesini engellemesi gerekir.
Ancak regresyon testi, mükemmel bir çözüm olmadan sorun yaratabilir. İşletme ihtiyaçları sıklıkla belirtilen bir terimdir: Özellikler geliştikçe eski özelliklerin kaybolmaması önemlidir. İyi test edilmiş bir kod tabanı bunu koruyabilir ancak gerçek kod tabanları her zaman bu ideale ulaşmaz. Bu konu ilerleyen bölümlerde daha ayrıntılı olarak ele alınacaktır.
Görsel testler
Görsel testte, bilinen iyi bir durumu (önceki bir ekran görüntüsü gibi) mevcut test çalıştırmasıyla karşılaştırarak kontrol etmek için bir web sitesinin durumunun ekran görüntüleri veya videoları alınır. Doğası gereği, HTML, CSS ve web sitesinin diğer bölümlerini görüntüleyebilmek için gerçek bir tarayıcının çalıştırılmasını gerektirir.
Kod tabanınızın tamamını çalıştıran uçtan uca testleri görsel olarak test etmek yerine, duyarlı kullanıcı arayüzlerini tetiklemek için yalnızca belirli bileşenleri (özellikle farklı ekran boyutlarında) oluşturan HTML "ekipmanları" oluşturmak yararlı olabilir. Bu, sadece JSDOM veya benzer çerçeveler kullanmaktan daha karmaşıktır.
Görsel testlerin başarısız olması, diğer türde arızalar için iyi bir işaret olabilir. Ancak karmaşık kullanıcı arayüzleri, test etmeye çalıştığınız özelliklerle ilgili olmayan nedenlerle (ör. kullanıcı arayüzünün görünümünü değiştiren diğer yeni özellikler veya önceki sürümlerden farklı şekilde yeni bir OS sürümü oluşturma emojisi) görsel testlerde başarısız olabilir.
Uçtan uca testler
Uçtan uca testler genellikle test piramidinin en üstünde yer alır. Bu araçlar, web uygulamanızla veya web sitenizle, belki belirli bir özellik etrafında yoğunlaşmış olarak gerçekleşen tam bir deneyim etkileşimini tanımlar ve genellikle WebdriverIO, Selenium veya Puppeteer gibi bir aracı tarafından kontrol edilen bir tarayıcıda çalışır. Bu aracı, kod tabanınızı üretimde dağıtıldığı gibi çalıştırabilir (ancak genellikle localhost'ta sunulurlar).
Sitenize bağlı olarak bu, test kullanıcısı olarak giriş yapmayı, önemli işlemler yapmayı ve sitenizin veya sisteminizin doğru durumda olduğunu onaylamayı içerebilir. Bu testler çok güçlü olsa da kimi zaman bakımları zor olduğundan sonraki bölümlerde bu tür testlere daha fazla örnek vereceğiz.
Bunları basitleştirmeye yönelik bazı taktikler, kapsamlarını küçültmeyi veya uygun olduğu durumlarda belirli bileşenlerin modelini oluşturmayı içerebilir. Örneğin, kullanıcıların sitenizde oturum açması gerekiyorsa ancak oturum açmak, test ettiğiniz özellik değilse test ortamları için, oturum açmadan veya ilişkili çerezleri oluşturmadan test denetleyicisinin kullanıcı gibi davranmasına olanak tanıyan bir işaret ayarlayabilirsiniz.
Uçtan uca testler, kod tabanınızın büyük kesitlerinde aynı anda test yapmanın çok güçlü yolları olabilse de bu tür büyük ölçekli testler, harici sistemlere olan bağımlılıkları nedeniyle güvenilir olma riskiyle karşı karşıya kalabilir. Ayrıca, örneğin her test bir giriş oluşturur veya değiştirirse genellikle veritabanınızda büyük miktarda test verisi bırakabilir. Kalan verilerin birikmesi bu tür bir testin nasıl başarısız olduğunu belirlemeyi zorlaştırabilir.
API testi
API testleri, yazılımınızın sağladığı API'lerin davranışını onaylama veya davranışlarını onaylamak için gerçek (muhtemelen aktif) API'lere erişmeyi ifade edebilir. Her iki durumda da, bu yaklaşım sistemler arasındaki soyutlamaları, nihayetinde birbirleriyle nasıl iletişim kuracaklarını test etmek için bunları bir entegrasyon testinde olduğu gibi birbirine entegre etmeden test eder.
Bu testler, arasındaki bağlantıları test ettiğiniz sistemleri çalıştırma zahmetine girmeden entegrasyon testi için temel bir öncü sağlayabilir. Ancak, gerçek dünyadaki sistemler testleri güvenilir olmayabilir.
Diğer türler
Kaynağınıza bağlı olarak, faydalı olabilecek farklı test yaklaşımları da vardır. Aşağıda bazı ilginç örnekler verilmiştir:
- Manuel test.
- Çevik yaklaşımda yaygın olarak kullanılan bir tür manuel test olan kabul testi, ürünün kullanıcının ihtiyaçlarını karşıladığını onaylar.
- Kaos testi, ne olacağını görmek, hatalı veri girildiğinde sitenin kilitlenmesini önlemek için rastgele veri girmeyi ifade eder.
- Başarısızlık testi, test edilen kodun kontrollü bir şekilde yanıt verdiğinden emin olmak için karmaşık sistemlerdeki hataları (ör. ağ hataları) kasıtlı olarak simüle eder.
- Derleme testi, kod tabanı derleme yapılarının, mevcut veya içeriklerinin ne olduğu kontrol edilerek oluşturulabileceğini onaylar. Bu test türü, karmaşık bir İYS'nin sonucunu kontrol etmek için faydalı olabilir.
Kod kapsamı
Kodunuzun yüzde kaçının otomatik testler tarafından test edildiğini ölçebilir ve bunu zaman içinde istatistik olarak raporlayabilirsiniz. %100 kod kapsamının hedeflenmesini önermiyoruz çünkü bu, gereksiz ek yüke ve ana kullanım alanlarını derinlemesine kapsamayan basit ya da kötü tasarlanmış testlere yol açabilir.
Kapsam, özellikle entegrasyon testlerini yazarken veya testler üzerinde çalışırken de yararlı bir araç olabilir. Tek bir testte hangi kodun test edildiğine dair bir yüzde veya satır satır dökümü görüntüleyerek nelerin eksik olduğu veya bundan sonra nelerin test edilebileceği hakkında bilgi sahibi olabilirsiniz.
Kaynaklar
Öğrendiklerinizi sınayın
Aşağıdakilerden hangileri bilinen test türleridir?