Cevap.

Otomatik testler, sistemi farklı seviyelerde kapsamlı test etmek için birim (unit), entegrasyon (integration) ve uçtan uca (end-to-end, E2E) olarak gruplandırılır.

Soru Tarihi: Bu sınıflandırma, uygulamaları hem parçalar halinde hem de bütün olarak test etme ihtiyacından doğmuştur. Bu yüzden test katmanları belirlenir:

belirli bir fonksiyon (unit)
parçalar arasındaki etkileşim (integration)
kullanıcı için çalışan tüm sistem (E2E)

Sorun: Hatalar genellikle yalnızca bir metodun mantığında değil, aynı zamanda bileşenlerin kesişim noktalarında ya da tüm sistemi dış hizmetlerle "gerçek" olarak çalıştırırken ortaya çıkar. Her şeyi tek bir yere koyarsanız, hatayı hızlı bir şekilde yerelleştirmek veya nerede oluştuğunu anlamak zorlaşır.

Çözüm:

Birim testleri izole bir kodu, genellikle fonksiyonlar veya basit sınıflar düzeyinde test eder. İleri durumlarda, sahte (mock) ve sabit (stub) kullanılır.
Entegrasyon testleri, birkaç bileşeni (örneğin, modül ve veritabanı) bir araya getirerek onların birlikte nasıl çalıştığını görmek için kullanılır.
Uçtan uca testler (E2E) kullanıcı senaryolarını taklit eder - "düğmeden sonuca" kadar olan tüm yolu.

Test türlerini ayırt etmek hayati önem taşır:

Destek maliyetlerini minimize etmek (E2E testler pahalıdır)
Hızlı geri bildirim sağlamak (birim testler ani sonuç verir)
Yanlış pozitiflerin sayısını azaltmak

Anahtar özellikler:

Testlerin doğru dağılımı güvenilir bir "piramidal" yaklaşım (test piramidi) inşa etmeye yardımcı olur.
Test stillerinin karışımı, hataların yerelleştirilmesinde sorunlara yol açar.
Her katmanın amacını net bir şekilde anlamak maksimum verimlilik sağlar.

Soruya yönlendirme.

Entegrasyon testlerini sadece "büyük" birim testleri olarak mı değerlendirebiliriz?

Hayır, entegrasyon testleri birden fazla bileşenin birlikte çalışmasını test eder ve yalnızca ayrı fonksiyonları değil. Bu yüzden, gerçek hizmetlerin birbiriyle etkileştiği durumlarda sahte (mock) kullanmak her zaman mümkün olmayabilir.

Tüm testler uçtan uca (E2E) olmalı mı?

Hayır, bu pahalı ve karmaşık bir yaklaşımdır. E2E testleri yalnızca kritik kullanıcı senaryoları için gereklidir, çoğu mantık diğer testlerle kapsanır.

Birim testleri her zaman hızlı mıdır?

Her zaman değil. Kodun izole edilmesi mümkün olmayabilir ya da bir metodun karmaşık dış kaynaklara bağımlılığı olabilir. Bu durumda test, birim testi olmaktan çıkar.

Tipik hatalar ve anti-deseni

Tüm testler sadece uçtan uca yazılır, geri bildirim çok yavaş olur.
Katmanlarda karışıklık: birim testi veritabanını veya API’yi çağırmaya başlar, E2E sahte (mock) üzerinde kurulur.
Sadece birim testleri bırakılır — bileşen kesişim noktalarındaki sorunlu hatalar yakalanmaz.

Gerçek hayat örneği

Olumsuz durum

Şirket, yalnızca E2E testleri ile temel işlevselliği kapsadı — her düzeltme gece kontrol edildi, testler istikrarsız bir şekilde başarısız oldu, hatalar geç keşfedildi.

Artılar:

Gerçek kullanıcı senaryoları kapsandı.

Eksiler:

Yavaş geri bildirim.
Arızaların nedenlerini araştırmak uzun sürüyor.
Çok fazla yanlış pozitif sonuçlar.

Olumlu durum

Ekip, test piramidalarını inşa etti: alt kısım — birim testleri, ortası — entegrasyon testleri, üst kısım — sadece en kritik E2E.