TDD Rehberi: Red‑Green‑Refactor Döngüsü

Özet: Pratik iş akışları, örnekler ve iş yararlarıyla Red‑Green‑Refactor TDD döngüsünde ustalaşın; daha temiz, bakımı kolay ve testle güvence altına alınmış kodlar yazın.

Giriş

Red‑Green‑Refactor Test‑Driven Development (TDD) döngüsü, küçük, doğrulanabilir adımlarla kod tasarımını yönlendirir ve yazılım kalitesini yükseltir. Önce başarısız bir test yazın (Red), testi geçecek en az kodu ekleyin (Green), sonra yapıyı iyileştirin (Refactor). Bu yaklaşım belirsizliği küçük parçalara böler ve kısa geri bildirim döngüleri sağlar; TDD yalnızca test yazmak değil, aynı zamanda API’yi ve kullanım şeklini testlerle tanımlayarak tasarımı yönlendirmektir².

TDD’yi benimseyen ekipler, otomasyon ve sık test geri bildirimi sayesinde daha güvenilir dağıtımlar yapma eğilimindedir; yüksek performanslı ekipler daha sık dağıtım ve daha hızlı geri dönüş süreleri gösterir³.

Red‑Green‑Refactor TDD: Pratik Rehber

TDD ritmini kavramak

TDD üç aşamada çalışır ve her biri belirgin bir amaç taşır:

• Red (başarısız test): En küçük yararlı davranışı tanımlayan tek bir otomatik test yazın. Test uygulama henüz mevcut olmadığından başarısız olmalıdır; bu, testin geçerli olduğunu gösterir.
• Green (geçmesini sağlama): Testi karşılamak için gereken en az miktarda kodu yazın; sadeliğe öncelik verin.
• Refactor (iyileştirme): Testler korunurken isimleri düzeltin, çoğaltmaları kaldırın ve kodun niyetini netleştirin.

Refactor adımını atlamak teknik borcun birikmesine yol açar; kodu gelecekte değiştirmeyi zorlaştırır.

Red‑Green‑Refactor ritminin faydaları

Aşağıdaki faydalar genellikle rapor edilir:

• Daha az regresyon ve daha hızlı hata düzeltme döngüleri².
• Test paketi, çalıştırılabilir bir dokümantasyon sağlar; yeni geliştiriciler testleri çalıştırarak sistemi hızlıca öğrenir.
• CI/CD ile birleştiğinde dağıtım sıklığını ve güvenilirliğini artırır; yüksek performanslı ekipler daha sık dağıtım ve daha hızlı geri dönüş süreleri elde eder³.

TDD döngüsünü uygulamada yürütmek

Aşağıdaki örnek, TDD’nin tasarımı nasıl şekillendirdiğini göstermek için TypeScript, React ve Jest kullanan basit bir LikeButton bileşeni içerir.

Red aşaması: ilk gereksinimi tanımlama

En basit gereksinim: bileşen çökmeksizin render edilmeli ve “Like” metnini göstermelidir. Bileşeni oluşturmadan önce testi yazıyoruz.

// LikeButton.test.tsx
import React from “react”;
import { render, screen } from “@testing-library/react”;
import LikeButton from “./LikeButton”;

describe(“LikeButton”, () => {
  it(“renders a button with the initial text “Like””, () => {
    render(<LikeButton />);
    const likeButton = screen.getByRole(“button”, { name: /like/i });
    expect(likeButton).toBeInTheDocument();
  });
});

Test çalıştırıldığında bileşen olmadığı için test başarısız olur — beklenen Red aşamasıdır.

Green aşaması: testi geçecek kadar olanı yazma

Testi karşılamak için asgari bileşeni oluşturun.

// LikeButton.tsx
import React from “react”;

const LikeButton = () => {
  return <button>Like</button>;
};

export default LikeButton;

Testleri tekrar çalıştırın; testler geçerse Green tamamlanmıştır.

Refactor aşaması: uygulamayı cilalama

Tipleri ekleyin ve genişlemeye hazırlıklı bir desen oluşturun.

// LikeButton.tsx (refactored)
import React, { FC } from “react”;

type LikeButtonProps = {};

const LikeButton: FC<LikeButtonProps> = () => {
  return <button>Like</button>;
};

export default LikeButton;

Testler hâlâ geçiyor; bu güvenlik ağı sayesinde kodu güvenle iyileştirebilirsiniz.

İterasyon örneği: butona tıklama

Yeni gereksinim: butona tıklamak metni “Liked” olarak değiştirir ve tekrar tıklamayı engellemek için butonu devre dışı bırakır. Yine başarısız bir testle başlıyoruz.

// LikeButton.test.tsx
it(“changes text to “Liked” and becomes disabled when clicked”, () => {
  render(<LikeButton />);
  const likeButton = screen.getByRole(“button”, { name: /like/i });
  fireEvent.click(likeButton);
  expect(likeButton).toHaveTextContent(“Liked”);
  expect(likeButton).toBeDisabled();
});

Geçmek için asgari mantığı ekleyin:

// LikeButton.tsx
import React, { FC, useState } from “react”;

type LikeButtonProps = {};

const LikeButton: FC<LikeButtonProps> = () => {
  const [liked, setLiked] = useState(false);
  const handleClick = () => setLiked(true);
  return (
    <button onClick={handleClick} disabled={liked}>
      {liked ? “Liked” : “Like”}
    </button>
  );
};

export default LikeButton;

Test paketini çalıştırın — hepsi yeşil. Her defasında bir küçük gereksinim ekleyin ve testlerle koruyun.

Kod kalitesi için iş vakası

TDD’nin mühendislik faydaları, iş değeriyle örtüşür: üretimde daha az hata, daha düşük destek maliyetleri ve daha güçlü marka itibarı sağlar. Hatalar erken yakalandığında düzeltilmeleri daha ucuzdur; ekipler yeni özelliklere daha fazla zaman ayırabilir. Ampirik çalışmalar, TDD uygulamalarının hata ayıklama çabalarını azalttığını ve kaliteyi iyileştirdiğini göstermiştir².

Disiplinli TDD uygulamaları, CI/CD süreçleriyle birleştiğinde dağıtım sıklığını ve güvenilirliği artırır. Yüksek performanslı ekipler sık dağıtım yapar; örneğin bazı yüksek performanslı ekipler günlük veya daha sık dağıtım gerçekleştirirken düşük performanslı ekipler aylık veya daha seyrek dağıtım yapar⁵.

Yayın sonrası hataları ve bakım maliyetlerini azaltma

Testleri önceden yazarak, yalnızca bir testi geçirecek kadar üretim kodu eklersiniz. Bu, güçlü bir güvenlik ağı sağlar ve beklenmeyen regresyonları azaltır; testleri tutarlı kullanan ekiplerde bakıma ve hata düzeltmeye giden çabaların azaldığı rapor edilmiştir².

Başta kaliteye odaklanmak, yazılımın toplam sahip olma maliyetini düşürür; çünkü teknik borcun zaman içinde birikmesini engellersiniz.

İşe alıştırmayı hızlandırma ve öngörülebilirliği artırma

Kapsamlı test paketi, çalıştırılabilir bir dokümantasyon görevi görür. Yeni geliştiriciler güncel olmayan wiki sayfaları yerine testleri çalıştırarak sistemin beklenen davranışını hızlıca öğrenir. Bu, işe alıştırma süresini kısaltır ve kıdemli mühendislerin üzerindeki yükü azaltır.

Tutarlı TDD uygulamaları ayrıca öngörülebilirliği artırır; işi küçük, test edilmiş döngülere bölmek tahminleri güvenilir kılar ve paydaş iletişimini kolaylaştırır¹.

Yaygın TDD tuzakları ve bunlardan kaçınma yolları

TDD uygulaması basitçe tarif edilir ama ustalaşması incelik ister. Aşağıdaki anti‑paternler TDD’nin faydalarını baltalar.

Birim testi altında entegrasyon testleri çalıştırmak

Sorun: Bir test bileşeni, servisleri, API istemcilerini ve bir veritabanını aynı anda çalıştırır; testler yavaş ve kırılgan olur.

Çözüm: Birimi izole edin. Dış bağımlılıklar için mock, stub ve fake kullanın. Entegrasyon kapsamı gerekiyorsa, ayrı entegrasyon testleri yazın. Gerçek birim testi ağ, dosya sistemi veya gerçek veritabanına dokunmamalıdır; hız ve güvenilirlik refactor yapmanıza izin verir⁴.

Davranış yerine uygulama detaylarını test etmek

Sorun: Testler iç uygulama detaylarını doğrular; refactor yaptığınızda testler kırılır ama davranış doğru kalır.

Çözüm: Genel API’yi ve gözlemlenebilir etkileri test edin. Girdi verildiğinde beklenen çıktı ne olmalı diye sorun; davranışı doğrulayan testler refactor’a dayanıklıdır.

Refactor adımını atlamak

Sorun: Geliştiriciler testleri geçtikten sonra refactor yapmadan yeni özelliklere yönelir; dağınık kod birikir.

Çözüm: Refactor’ı zorunlu bir adım olarak kabul edin. Testler geçiyorken küçük temizlemeler güvenlidir ve zaman içinde değiştirmesi kolay bir kod tabanı sağlar.

TDD’yi ekibinize ve miras koda entegre etme

TDD’yi benimsemek teknik olduğu kadar kültürel bir değişimdir. Uygulamalı öğrenmeyi teşvik edin, testleri ekibin “Yapıldı” tanımına dahil edin ve küçük kazanımları kutlayın.

Ekip içinde TDD’yi savunmak

Pratik yollar:

• Pair programming: Deneyimli bir geliştirici Red‑Green‑Refactor döngüsünde ekip arkadaşına rehberlik eder.
• Mob programming: Zor sorunlar için sürücüyü rotasyonla değiştirerek bilgiyi yaymak.
• Lunch‑and‑learn oturumları: Kod tabanınızda TDD örnekleri gösterin.

Küçük başlayın ve erken test yakalamalarını ekip için kanıt noktalarına çevirin.

Karakterizasyon testleriyle miras kodu evcilleştirmek

Testsiz ve riskli kodda değişiklik yaparken, mevcut davranışı belgelemek için karakterizasyon testleri yazın. Bu testler bugün sistemin nasıl davrandığını doğrulayarak refactor veya özellik eklemeyi güvenli kılar.

CI/CD boru hatlarıyla kaliteyi otomatikleştirme

Test paketini her commit’te CI’da çalıştırın. Bu anında geri bildirim sağlar, kalite kapılarını uygular ve testlerin geçmesi birleşmeden önce zorunlu olur. Otomasyon, test geri bildirim döngüsünü hızlı ve güvenilir tutar; CI/CD uygulamaları dağıtım sıklığını ve güvenilirliği artırır³.

İlgili rehberler: CI/CD Rehberi, React Testleri.

En çok sorulan TDD sorularınız, cevaplandı

TDD diğer test türlerinin yerini alır mı?

Hayır. TDD bir tasarım aracı olarak birim testlerine odaklanır; entegrasyon testleri ve uçtan uca testler hâlâ gereklidir.

Veritabanları veya dış API’lerle TDD’yi nasıl kullanırım?

Kodu dış bağımlılıklardan izole edin, mock ve stub kullanın. Mantığı birim içinde test edin ve gerçek entegrasyonları ayrı bir test paketinde saklayın.

Basit UI bileşenlerini test etmek buna değer mi?

Evet. Davranışı test ettiğinizde, uygulamayı değil. Bir butonun doğru etiketi gösterip göstermediğini veya tıklanınca doğru eylemi tetikleyip tetiklemediğini doğrulayın.

Hızlı SSS — Kısa cevaplar

Q: Red‑Green‑Refactor döngüsünün temel yararı nedir?
A: Küçük, doğrulanabilir adımlarla belirsizliği azaltmak ve tasarımı testlerle yönlendirmek.

Q: Test yazmayı nerede sınırlandırmalıyım?
A: Birim testlerini izole tutun; entegrasyon ve uçtan uca testleri ayrı katmanlarda çalıştırın.

Q: Refactor’ı atlamanın maliyeti nedir?
A: Teknik borç birikir; ileride değişiklik yapmak zorlaşır ve hata riski artar.

Ek kısa Q&A — Özet ve uygulama odaklı cevaplar

Q: TDD’ye nereden başlamalıyız?
A: Küçük başlamak en iyisi: tek bir yeni özellik veya düşük riskli bir hata üzerinde Red‑Green‑Refactor uygulayın.

Q: TDD benim ekibime zaman kaybettirir mi?
A: Kısa vadede biraz yavaşlama olabilir, ama uzun vadede daha az regresyon ve daha hızlı hata düzeltme sağlar, böylece toplam maliyet düşer².

Q: TDD’yi miras koda nasıl tanıtırım?
A: Karakterizasyon testleriyle başlayın, CI’da testleri çalıştırın ve küçük, değerli kazanımları ekip içinde görünür kılın.

Hızlı Başlangıç — 3 Kısa Q&A Bloğu

Başlarken

Q: İlk testi ne için yazmalıyım?
A: En basit görünen kullanıcı davranışını hedefleyin — bileşen render’ı veya temel API çıktısı gibi.

Q: Test başarısız olunca hemen kod yazmalı mıyım?
A: Evet; Red adımı testin geçerli olduğunu gösterir, sonra Green ile en az kodu ekleyin.

Q: Ne kadar sık refactor yapmalıyım?
A: Her küçük Green adımından sonra kısa, güvenli refactor’lar yapın.

Sık karşılaşılan problemler

Q: Testler yavaş çalışıyor, ne yapmalıyım?
A: Test kapsamını gözden geçirin; birim testlerini izole edin, entegrasyon testlerini ayrı gruplarda çalıştırın.

Q: Testler sık kırılıyor, sebep ne olabilir?
A: Muhtemelen iç uygulama detaylarına bağlısınız; testleri gözlemlenebilir davranışlara taşıyın.

Q: Miras kodda nereden başlanır?
A: Kritik yollar için karakterizasyon testleri yazın ve küçük refactor’larla ilerleyin.

İş ve metrikler

Q: TDD’nin iş değerini nasıl ölçerim?
A: Dağıtım sıklığı, geri dönüş süresi, hata sayısı ve destek taleplerindeki düşüş gibi metrikleri izleyin.

Q: Hangi metrikler iyileşirse TDD işe yarıyor demektir?
A: Daha sık başarılı dağıtımlar, daha kısa lead time ve daha az üretim hatası göstergeleridir³.

Q: Test yazımını ekipçe nasıl şart koşarım?
A: “Yapıldı” tanımına testleri dahil edin ve CI başarısını kalite kapısı olarak kullanın.

Kaynaklar ve Son Notlar

Bu rehberin temel mesajı: küçük, testle korunmuş döngülerle tasarımı yönlendirmek hem geliştirici deneyimini hem de iş sonuçlarını iyileştirir. Küçük başlayın, otomasyonu artırın ve ekip içinde paylaşılan uygulamalar geliştirin.