Red-Green-Refactor TDD: Pratik Rehber

Özet: Pratik iş akışları, örnekler ve iş yararlarıyla Red‑Green‑Refactor TDD döngüsünde ustalaşın; daha temiz ve bakımı kolay kodlar oluşturun.

Giriş

Red‑Green‑Refactor Test‑Driven Development (TDD) döngüsü, ekiplerin güvenilir yazılımlar tasarlayıp teslim etmesine yardımcı olan basit, disiplinli bir iş akışıdır. Ö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 adımlar belirsizliği küçük, doğrulanabilir parçalara böler ve yazılım kalitesini artırır. TDD sadece test yazmak değil, kodun nasıl kullanılacağını düşünerek tasarımı yönlendirmektir².

TDD’yi benimseyen ekipler, kısa geri bildirim döngüleri ve otomasyon sayesinde daha sık dağıtım yapma eğilimindedir; yüksek performanslı ekipler veride daha sık dağıtım ve daha kısa değişiklik süreleri gösterir³.

Test‑Odaklı Geliştirmenin Ritmi

Birçok geliştirici TDD’nin yalnızca test yazmak olduğunu düşünür, ama TDD esasen bir tasarım pratiğidir. Testi önce yazmak, uygulamayı oluşturmadan önce API’yi ve beklenen davranışı düşünmeye zorlar; bu da küçük, kasıtlı ilerlemeyi teşvik eder.

Üç aşamayı anlamak

Her aşamanın belirgin bir amacı vardır ve işi küçük, doğrulanabilir tutar:

• Red (başarısız test): En küçük yararlı davranışı temsil eden tek bir otomatik test yazın. Test, uygulama henüz mevcut olmadığından başarısız olur; başarısızlık 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ği şıklığın önüne koyun.
• Refactor (iyileştirme): Testler güvenlik ağı sağlarken isimleri düzeltin, çoğaltmaları kaldırın ve davranışı değiştirmeden yapıyı sadeleştirin.

Refactor adımını atlamak teknik borcun birikmesine yol açar ve ileride değişiklik yapmayı zorlaştırır.

Red‑Green‑Refactor ritminin faydaları

Bu ritmi benimsemek, ekiplerin öngörülebilir ve kendinden emin çalışmasına yardımcı olur. TDD pratikleri, ekip ve pazar koşullarına göre farklı şekillerde uygulanabilir¹.

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 — bu 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 hızlıca örtüşür. Üretimde daha az hata, daha düşük destek maliyetleri ve güçlü bir 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ı 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ı ekiplerin ölçümlerinin diğer gruplara göre çok daha iyi olduğu gösterilmiştir³.

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

Testleri önceden yazarak, sadece bir testi geçirecek kadar üretim kodu eklenir. Bu, güçlü bir güvenlik ağı sağlar ve beklenmeyen regresyonları azaltır. Bir dizi çalışma, TDD ve otomatik testleri tutarlı kullanan ekiplerde daha düşük hata oranları bildirmiş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³.

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â gerekli.

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.

Sıkça Sorulan Kısa Cevaplar (Hızlı SSS)

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.