Test otomasyonuna ilk girişte herkes aynı çizimi görür: en altta geniş bir birim test tabanı, ortasında entegrasyon testleri, tepesinde bir avuç uçtan uca senaryo. Çizim yirmi yıldır değişmedi; değişen, hangi katmana neyin dahil olduğu. 2026'nın React Server Components ve API rotaları dünyasında piramidi yeniden tartmak gerekiyor, çünkü katmanların sınırları bulanıklaştı.

Katmanlar neyi kanıtlar?

Birim testi tek bir fonksiyonun veya bileşenin sözleşmesini doğrular. Hızlıdır, saniyede onlarcası çalışır, hata mesajı milimetrik ölçer. Entegrasyon testi ise parçaların birbirine nasıl bağlandığını sorar: veritabanı katmanı gerçekten sorguyu doğru mu çeviriyor, rota işleyicisi doğru statüyü mü döndürüyor, form verisi doğrulamadan tabloya ulaşıyor mu? Uçtan uca testse kullanıcının tarayıcıdan geçtiği yolu, yani gerçek iş akışını kanıtlar; menüye tıklanır, form doldurulur, sonucun ekranda görünmesi beklenir. Üç katman üç farklı soru sorar ve hiçbiri diğerinin yerine geçmez.

Klasik hata, piramidi tersine çevirmektir: her şeyi uçtan uca kapsamak. Bu testler yavaştır, ortamına bağlıdır ve her bozulan derlemede ekibi "geçici kusurlu" (flaky) testlerin peşinden koşturur. Kırmızı ışık artık hata habercisi değil, rutin bir gürültüdür; o an test kültürü çökmeye başlar. Piramidin şekli tesadüf değildir: hızlı test çoktur çünkü sık koşulur, yavaş test azdır çünkü ancak kritik yollarda düşünülür.

Bu sitedeki denge

Örnek vermek gerekirse yorum onay kuyruğu gibi kritik bir akışı üç katmanla birlikte test etmek isteriz. Katman dağılımı kabaca şöyle çalışır:

// 1) Birim: saf fonksiyon, saniyeler içinde döner
it("şüpheli yorumu işaretler", () => {
  const sonuc = heuristikKontrol({ gonderi: "ücretsiz http://", link: 4 });
  expect(sonuc.supheli).toBe(true);
});

// 2) Entegrasyon: veritabanı gerçek, zaman sahte
it("işaretli yorum beklemede düşer", async () => {
  await rota.post("/api/comment", gecerliIstek);
  const kayit = await db.select().from(comments);
  expect(kayit[0].flagged).toBe(1);
});

// 3) Uçtan uca: tarayıcıda tam akış
test("yönetici onaylar, ziyaretçi görür", async ({ page }) => {
  await page.goto("/makale/x");
  await page.getByRole("button", { name: "Onayla" }).click();
  await expect(page.getByText("beklemede")).toBeHidden();
});

Oranlara takıntılı olmayın; ama tablo bir şey söylüyorsa dinleyin: birim testleriniz uçtan uca testlerinizin altına düşüyorsa, mantığı bileşenlere gömmüşsünüz demektir. Refaktör yapamaz hale gelirsiniz, çünkü her düzenleme onlarca testi birlikte kırar. Sağlıklı bir tabloda kritik iş kuralları neredeyse tamamen birim katmanda yaşar; arayüz katmanı ise yalnızca sunumun kendisini taşır.

Piramit mi, kupa mı?

Bazı ekipler "test kupası" (Test Trophy) diye tabir edilen, entegrasyon katmanını şişiren bir model öneriyor. Gerekçe sağlam: modern çatılar, bileşeni sahte bağımlılıklarla değil gerçek veriyle çalıştırmayı kolaylaştırdı. Yine de tepe katmanı küçük tutmak 2026'da da geçerli çünkü tek şey değişmedi: yavaş test, dinlenmeyen test.

Birim katmanınız genişse refaktörü göğüslersiniz, entegrasyon katmanınız sağlıklıysa mimari sapmayı erken görürsünüz, uçtan uca katmanınız kısaysa gece derlemesi de kısa kalır. Dengenin kendisi bir mimari kararıdır ve her büyük değişiklikte yeniden tartılmalıdır. Piramit bir dogma değil, başlangıç noktasıdır: ekibinizin ritmine ve ürününüzün risk haritasına göre yeniden okuyun.