Uçtan Uca Test (E2E Test) Nedir?
Kısa tanım
Uçtan uca test (end-to-end test, E2E), bir uygulamayı gerçek kullanıcının kullandığı gibi, arayüzden veritabanına kadar tüm katmanları birlikte çalıştırarak sınayan otomatik testtir. Bir test aracı tarayıcıyı açar, sayfalara gider, butonlara tıklar, form doldurur ve sonuçta ekranda görünen şeyi doğrular. Bileşenlerin birbirine doğru bağlandığını en gerçekçi biçimde gösterir, ancak en yavaş ve bakımı en zor test türüdür.
Diğer adları: E2E test, end-to-end test, E2E testi, end-to-end testing
Kullanıcının yolunu baştan sona yürümek
Birim testi tek bir fonksiyonu yalıtarak sınar; E2E testi ise hiçbir şeyi yalıtmaz. Gerçek bir tarayıcı (çoğu zaman ekransız, “headless” modda) gerçek ön yüzü açar, o ön yüz gerçek arka uca istek atar, arka uç test veritabanına yazar. Test bu zincirin herhangi bir halkası koptuğunda kırılır: yanlış bir API adresi, eksik bir veritabanı migrasyonu, hatalı bir CORS ayarı ya da yanlış yere taşınmış bir buton.
Bugün bu iş için en yaygın araçlar Playwright, Cypress ve Selenium'dur. Aşağıdaki Playwright testi bir e-ticaret sitesinde misafir kullanıcının ürünü sepete ekleyip ödeme adımına geçebildiğini doğrular:
import { test, expect } from "@playwright/test";
test("misafir kullanıcı ödeme adımına ulaşabilir", async ({ page }) => {
await page.goto("/urun/kahve-degirmeni");
await page.getByRole("button", { name: "Sepete ekle" }).click();
await page.getByRole("link", { name: "Sepet" }).click();
await expect(page.getByText("Kahve Değirmeni")).toBeVisible();
await page.getByRole("button", { name: "Ödemeye geç" }).click();
await expect(page).toHaveURL(/\/odeme/);
});Öğeleri CSS sınıfıyla değil rol ve erişilebilir adla (getByRole) bulmak bilinçli bir tercihtir: tasarım değiştiğinde sınıf adları değişir, “Sepete ekle” butonu ise kullanıcı için aynı kalır.
Test piramidi: neden az ama seçilmiş E2E testi?
Test piramidi, otomatik testlerin nasıl dağıtılması gerektiğini anlatan bir modeldir. Tabanda çok sayıda birim testi, ortada daha az entegrasyon testi, tepede ise az sayıda uçtan uca test bulunur.
| Katman | Tipik sayı | Süre | Kırıldığında ne söyler? |
|---|---|---|---|
| Birim | Yüzler, binler | Milisaniye | Hangi fonksiyonun bozulduğunu tam olarak |
| Entegrasyon | Onlar, yüzler | Saniye | Hangi iki parçanın uyuşmadığını |
| Uçtan uca | Birkaç, birkaç düzine | Saniyeler, dakikalar | Bir kullanıcı akışının bozulduğunu, ama çoğu zaman nedenini değil |
Piramidin ters dönmüş hali, yani testlerin çoğunun tarayıcı üzerinden yazıldığı ve birim testlerinin az olduğu düzen, sık rastlanan bir sorundur. Böyle bir paket yarım saatte biter, sık sık sebepsiz kırılır ve kırıldığında hatanın yerini bulmak için yine elle hata ayıklamak gerekir. E2E testleri iş açısından kritik akışlara ayrılmalı, ayrıntılı kural kombinasyonları alt katmanlarda sınanmalıdır.
Flaky testler: aynı kod, farklı sonuç
Kod değişmediği halde bazen geçip bazen kırılan teste flaky test denir. E2E testleri bu soruna en açık olanlardır, çünkü ağ, tarayıcı, zamanlama ve paylaşılan veri gibi kontrolü zor çok sayıda parçaya dayanırlar. En sık sebepler:
- Sabit beklemeler: “2 saniye bekle” satırı hızlı makinede gereksiz, yavaş CI sunucusunda yetersizdir. Bunun yerine öğe görünene kadar otomatik bekleyen doğrulamalar kullanılmalıdır.
- Paylaşılan test verisi: İki test aynı kullanıcı hesabını değiştiriyorsa sonuç çalışma sırasına bağlı hale gelir. Her test kendi verisini oluşturmalı ve temizlemelidir.
- Dış servisler: Gerçek ödeme altyapısı, harita veya e-posta servisi testin kontrolü dışındadır; test ortamında bunların sandbox sürümleri ya da taklitleri kullanılır.
- Animasyon ve yükleme durumları: Henüz yerine oturmamış bir butona tıklamak yanlış öğeye tıklamaya yol açabilir.
Otomatik yeniden deneme (retry) flaky testleri gizler, çözmez. Yeniden denemeyle geçen testleri ayrıca raporlamak, en çok sorun çıkaranları karantinaya alıp düzeltmek ve flaky oranını izlemek gerekir. Aksi halde ekip kırmızı testleri “yine o test” diye görmezden gelmeye başlar ve gerçek bir hata da aynı muameleyi görür.
Nerede ve ne zaman çalıştırılır?
E2E testleri genellikle CI/CD hattında, uygulama üretime benzeyen bir staging ortamına kurulduktan sonra çalışır; geçemezlerse canlıya çıkış durur. Canlıya çıktıktan hemen sonra birkaç kritik akışı deneyen kısa bir “smoke test” seti de yaygındır. Aynı senaryoların canlı ortamda belirli aralıklarla tekrarlanması ise artık test değil sentetik izleme olarak adlandırılır ve kullanıcılardan önce sorunu fark etmeye yarar.
Hangi akışların E2E testini hak ettiğine karar vermek için basit bir soru yeterlidir: bu akış bozulursa para, müşteri ya da veri kaybı olur mu? Giriş yapma, kayıt, sepet ve ödeme, teklif formu ve şifre sıfırlama genellikle listenin başındadır.