Test-Driven Geliştirme (TDD) ve BDD Yaklaşımları: Pratik Rehber [2026]

TDD ve BDD: Yazılım Geliştirmeyi Tasarımdan Güvenlikli Hale Getirmek

Geleneksel yaklaşımda:

1. Geliştirici feature kodlar (belirtim ne anlıyor ise öyle anlıyor)
2. Test yazılır (eğer yazılırsa)
3. Hatalar bulunur

TDD ve BDD yaklaşımında:

1. Test yazılır (ÖNCE!)
2. Kod yazılır (test yeşil olana kadar)
3. Test başarıysa, specification doğru

Bu iki yaklaşım arasındaki fark sadece test olmadığı açık. Bu, yazılım tasarımını test ile yapılandıran bir felsefe.

TDD: Red-Green-Refactor Döngüsü

TDD'nin üç adımı:

Adım 1: Kırmızı (Red) - Başarısız Test Yazı

Henüz özellik yazılmadığı için, test başarısız olur. Bunu kasıtlı olarak yapıyoruz.

Örnek: Ödeme özelliği. Bir metot yazacağız: calculateDiscount(). İlk test, 1000 lira tutar için %10 indirim (100 lira) beklediğini kontrol eder. Metot henüz yazılmadığı için, test başarısız olur. KIRMIZI.

Adım 2: Yeşil (Green) - Minimal Kod Yazarak Testi Geçir

Testi geçirmek için en minimal kodu yaz. Elegant olmadığı sorun değil, hızlı olması önemli. calculateDiscount() metodu basitçe "100" döndürebilir. Test geçer. YEŞİL.

Adım 3: Refactor - Kodu Temizle

Test yeşil kaldığı sürece, kodu güvenle refactor edebilirsin. Test senin güvenlik ağın. Şimdi calculateDiscount() metodunu gerçekçi hale getirelim: 1000 lira ve üzeri için %10, 500-999 için %5, diğerleri için 0. Test hala yeşil kalmalı.

Tekrar: Daha Fazla Test Ekle

Başka bir sınır durumu (edge case) test et: 500 lira tutar için %5 indirim (25 lira). Bu test kırmızı olur. Kodu güncelledikten sonra yeşil. Tekrar refactor.

Bu döngü tekrar tekrar: Red -> Green -> Refactor -> Red -> Green -> ...

TDD ve BDD yaklaşımlarının yazılım kalitesi çerçevesindeki yeri hakkında daha kapsamlı bilgi için, Yazılım Test ve Kalite Güvence rehberi adresini inceleyebilirsiniz.

TDD Avantajları

1. Küçük Tasarım Adımları

Testi yazarken, ne sağlamalı olduğunu düşünüyorsun. Büyük, monolitik fonksiyonlar yazamazsan; test yazamaz.

2. Kusurlu Tasarımları Erken Yakala

Eğer fonksiyon çok karmaşık ise, yazması zor olur. İşte bu noktada tasarımı simplify edersin. Kodun yazılmadan ÖNCE.

3. Düşük Regresyon Risk

Test hep güncel. Eğer refactor ederken başarısız olursa, hemen fark edersin.

4. Belirtim Belgesi Olarak Test

Test, fonksiyonun ne yaptığının en iyi belgesidir. Başka bir geliştirici, testi okuduğunda hemen anlar.

TDD Dezavantajları

1. Başlangıçta Yavaş

Kod yazarken test yazmak, ilk bakışta daha yavaş gibi gözükür. Ancak uzun vadede, debuggin zamanı kısalır ve hata oranı düşer.

2. Riskli Özelliklerde Kullanılması Zor

Yeni algoritma geliştiriyorsan, ne sonuç alacağını bilmiyorsun. Test yazamaz.

3. Legacy Code'da Uygulanması Zor

Eski kodların test yazması imkânsız olabilir. "Bu değişikliğe test yazılamaz mı?" diyenler, legacy code ile uğraşmış.

4. Ekip Kültürü

TDD bir disiplin ve kültür meselesi. Ekip buna inanmazsa, zorlama başarısız olur.

BDD: Davranış Odaklı Geliştirme

BDD, TDD'nin bir adım ilerisi. Yazılımcı dilinde değil, iş dilinde test yazarsın. Bu sayede, business analyst'ler ve QA'cılar da test yazabilir.

BDD ile Gherkin Dili

İnsan dilini andıran bir test dili. Örneğin: Feature: User Login Scenario: Valid credentials. Given user is on login page. When user enters username and password. And user clicks login button. Then user should be logged in. And user should see welcome message.

Bu script, teknik olmayan birisi tarafından yazılabilir. QA yöneticisi, proje müdürü yazabilir.

Cucumber: Gherkin'i Oto-Teste Çevirme

Cucumber, Gherkin scriptlerini Java, Python, JavaScript testlerine çevirir. Her "Given", "When", "Then" satırı, bir step definition'a eşlenir. Örneğin, "user is on login page" adımı, browser'ı login sayfasına açar; "user enters username" adımı, ilgili input alanına veri girer; "user should be logged in" adımı login durumunu kontrol eder.

Gherkin script koşulunca:

1. Browser login sayfasını aç
2. Username gir
3. Password gir
4. Login button tıkla
5. Logged in durumunu kontrol et

TDD vs BDD vs Geleneksel Test Karşılaştırması

Yönlü	TDD	BDD	Geleneksel
Test Yazması	Geliştirici	Business Analyst	QA Yöneticisi
Test Dili	Java, Python, vb	Gherkin (İnsan dili)	Java, Python, vb
Test Zamanı	Kodun yazılmasından ÖNCE	Özellik yazılmadan ÖNCE	Özellik yazıldıktan SONRA
Başarılı Oranı	Yüksek (tasarım erken yapıldığında)	Yüksek (tüm stakeholder katılım)	Orta (tasarım ve uygulama ayrı)
Kod Kalitesi	Mükemmel (small, testable)	Mükemmel	Değişken
Geliştirme Hızı	İlk bakışta yavaş, uzun vadede hızlı	Orta	Hızlı ilk, sonra yavaş hata düzeltmesi
Belirtim	Test kod olarak	Gherkin belirtimi olarak	Ayrı belirtim belgesi

TDD/BDD Ne Zaman Gerekli?

TDD Kullan:

• Karmaşık algoritma
• Kritik business logic
• Test yazması kolay (birim test)
• Geliştirici deneyimi iyi

BDD Kullan:

• Business analyst'ler ve QA'cılar test yazacak
• Özellik gereksinimleri muğlak
• E2E test senaryoları
• Dokümantasyon önemli

Geleneksel Test:

• Hızlı MVP geliştirme
• Proof of Concept
• Prototyping

TDD/BDD Benimseme Zorlukları

1. Ekip direnişi: "Neden test yazayım, sonra kod yazayım? Direk kod yazı!" Bu kültürü değiştirmek uzun zaman alır.

2. Öğrenme eğrisi: Gherkin, Cucumber, step definition'lar öğrenmek ilk başta kafa karıştırıcı.

3. Sahte başarı: Testler yazılıyor, ama asıl özellikler çıkmıyor. Proje yöneticisi: "Niye bu kadar yavaş?"

4. Değişken gereksinimler: Gereksinimler değişirse, testler de değişmeli. Bu da iş yükü artırır.

Best Practices

1. Incrementally Başla

Tüm ekibi bir anda TDD'ye geçiştirme yapma. Yeni özelliklerden başla, eski kodları dahil etme (ilk aşama).

2. Eğitim Ver

Takım TDD ve BDD'yi anlamalı. Workshop yapılmalı, örnek projeler hazırlanmalı.

3. Metric Takibi Yap

Test kapsama oranı, test başarı oranı, regresyon hatası - metrikler takip etmelidir.

4. Tool'lar Seç

JUnit (Java), pytest (Python), Jest (JavaScript), Cucumber, Robot Framework gibi araçlar.

5. Refactoring'i Varsay

TDD ile kod, sık sık refactor edilir. Bu normal. Refactoring, "kodu tersine yazma" değildir, "tasarımı iyileştirme"dir.

Gerçek Hayat Örneği: E-ticaret Ödeme Sistemi

BDD ile belirtim, ödeme işlemi için şu senaryoları içerebilir:

Senaryo 1: Geçerli kart ile başarılı ödeme. Müşteri sepete 100 dolarlık ürün ekler, checkout'a gider, kart bilgisini girer, ödemeyi onayla. Ödeme işlenir, sipariş onayı gösterilir, sistem'de sipariş kaydı oluştur.

Senaryo 2: Yetersiz bakiye ile başarısız ödeme. Müşteri sepete ürün ekler, checkout'a gider, yetersiz bakiyesi olan kartı girer, ödemeyi onayla. Ödeme reddedilir, hata mesajı gösterilir, sipariş kaydı oluşturulmaz.

Ekip bu senaryoları okuyor ve anladığından emin olur. Sonra step definition'lar yazılır, automation kurulur.

Avantaj: Business analyst, proje yöneticisi, geliştirici, QA - hepsi aynı dili konuşuyor.

TDD/BDD Benimseme Maliyeti ve ROI

TDD benimseme, kuruma initial maliyet yaratır ama uzun vadede tasarrufu sağlar:

1. Eğitim ve Kurulum (Başlangıç)

• TDD Eğitimi (3 gün, 20 geliştirici): 15.000 USD
• Test Framework Kurulumu: 5.000 USD
• CI/CD Integration: 10.000 USD
• Coaching (3 ay, bir saat/hafta): 12.000 USD
• Başlangıç Maliyeti: 42.000 USD

2. Geliştirme Hızı Etkisi

Ön TDD (ilk 3 ay):

• Feature çıkış hızı: Yavaş, bir özellik 2 katı zaman alıyor
• Ekip frustrasyonu: "Niye bu kadar yavaş?"
• Hata oranı: Hala yüksek (disiplin henüz kurulmadı)

TDD benimseme sonrası (ay 4-12):

• Feature çıkış hızı: Normal seviyesine dönüyor
• Hata oranı: %40-50 azalır
• Refactoring güveni: Artıyor (test safety net)
• Debugging süresi: %60 azalır

Uzun vadede (yıl 2+):

• Feature çıkış hızı: %20-30 daha hızlı
• Technical debt accumulation: %70 daha az
• Production bug'lar: %70 daha az
• Geliştirici moral: Yüksek (kodu değiştirebilir güveni)

3. ROI Hesapı

Bir kurum, 50 geliştirici, 100 feature/yıl çıkarıyor:

Öncesi (No TDD):

• Geliştirme: 50 dev x 200K USD/yıl = 10 milyon USD
• Debugging/QA: 20% overhead = 2 milyon USD
• Production support: Hata düzeltme = 1 milyon USD
• Yıllık Toplam: 13 milyon USD

TDD sonrası (Yıl 2+):

• Geliştirme: 50 dev x 200K USD/yıl = 10 milyon USD (feature hızı %20 artıyor)
• Debugging/QA: 10% overhead (debugging daha hızlı)
• Production support: 300K USD (hata %70 azaldı)
• Yıllık Toplam: 10.3 milyon USD

Tasarruf: 2.7 milyon USD/yıl = %20 kazanç

4 yıl sonra: Eğitim 42K, yıllık tasarruf 2.7M x 3 yıl (yıl 2, 3, 4) = 8.1M - 42K = 7.96 milyon USD net tasarruf

TDD Yazımı Best Practice'ler

1. Arrange-Act-Assert Deseni

Test yazımının en temel deseni, üç bölüme ayrılır. Birinci bölüm (Arrange), test verisini ve gerekli nesneleri hazırlar. İkinci bölüm (Act), test edilecek fonksiyonu çalıştırır. Üçüncü bölüm (Assert), sonuçları kontrol eder. Bu yapı, testleri okunabilir ve bakımı kolay hale getirir.

Örneğin, indirim hesaplama fonksiyonu için: önce Order nesnesi ve DiscountCalculator'ı hazırlayacaksınız, ardından calculateDiscount() metodunu çalıştıracaksınız, son olarak dönen değerin 100 olduğunu kontrol edeceksiniz.

2. Edge Case'leri Test Et

Sadece normal senaryoları test etmek (happy path) yeterli değildir. Sınır durumları (boundary), null değerler, boş veri setleri gibi edge case'ler mutlaka test edilmelidir.

Örneğin, indirim hesaplama fonksiyonu için: sıfır lira için indirim olmadığını, negatif tutar için exception atıldığını, çok büyük tutarlar için integer overflow'un doğru şekilde işlendiğini test etmelisiniz.

3. Test İsimlendirilmesi (Descriptive)

Test adları, açıklayıcı olmalı ve hangi durumu test ettiğini, beklenen sonucun ne olduğunu ifade etmelidir. Kötü bir ad: testDiscount(). İyi bir ad: calculateDiscount_For1000Amount_Returns100Discount(). Bu adlandırma deseni (methodName_Scenario_ExpectedResult), testleri otomatik olarak belgelendirmiş olur.

4. Test Isolation

Her test, bağımsız olmalı ve başarısızlığı diğer testleri etkilememeli. Test öncesinde (setup), temiz bir durum oluşturulmalı. Test sonrasında (teardown), kaynaklar ve state'ler temizlenmelidir. Bu sayede, testler herhangi bir sırada ve paralel olarak çalıştırılabilir.

BDD Senaryo Yazımı

Gherkin Syntax (İnsan dilinde)

BDD senaryoları, Gherkin diliyle yazılır. Yapı, Feature (özellik) tanımlanarak başlar. Her özelliğin altında, Scenario'lar listelenir. Her scenario, Given (varsayılan durum), When (gerçekleştirilen aksiyon), Then (beklenen sonuç) adımlarından oluşur.

Örneğin, kullanıcı kaydı özelliği için: Senaryolardan biri, geçerli email ile başarılı kayıt. Başka bir senaryo, yinelenen email ile başarısız kayıt. Bu senaryolar, İnsan dilinde yazılmış, teknik olmayan kişiler tarafından da anlaşılabilir olacak şekilde yapılandırılır.

Step Definition (Uygulama)

Gherkin senaryolarının her adımı, yazılımcılar tarafından uygulama kodu (Step Definitions) ile eşleştirilir.

Örneğin, "user is on registration page" adımı, tarayıcıyı registration sayfasına açan kod ile bağlanır. "User enters email" adımı, email input alanına veri yazan kod ile bağlanır. "User should see welcome message" adımı, welcome mesajının görüntülendiğini kontrol eden kod ile bağlanır.

Bu şekilde, İnsan dilinde yazılmış senaryo, otomatik test olarak çalıştırılabilir hale gelir.

TDD Framework'leri ve Araçları

Framework	Dil	Avantajı	Dezavantajı	Kurulum
JUnit	Java	Industry standard, geniş ecosystem	Verbose	Kolay
pytest	Python	Pythonic, concise syntax	Daha az plugin	Çok kolay
Jest	JavaScript	React/Vue/Angular integration	Başlangıçta yavaş	Kolay
Cucumber	Multi	BDD syntax, non-technical friendly	Learning curve	Orta
Robot Framework	Multi	Keyword-driven, UI/API test	Performans	Orta
Spock	Groovy	DSL based, expressive	Niche language	Orta

TDD Başarısızlık Hikayeleri

Başarısız Case 1: Kurumsal Direniş

Şirket: "TDD benimseyeceğiz" Sonuç: 3 ay sonra, ekip "bu hızlı değil" diyerek TDD terk ediyor.

Neden: Executive sponsor yok, kültür desteği yok. Ders: TDD, top-down mandate ile başarısız. Bottom-up adoption daha etkili.

Başarısız Case 2: Yanlış Beklenti

Yönetici: "Hata %0 olacak" Geliştirici: "Test yazıyorum, ama hata hala var" Sonuç: Güvensizlik, TDD bırakıp manual debug'a dönüş.

Neden: %0 hata unrealistic. İyi TDD, %90-95 hatayı bulur. Ders: Realistic beklenti, başlangıçtan set et.

Başarısız Case 3: Test Kalitesi İhmalı

Takım: "Test yazıyor ama kötü test" Sonuç: Test ve kod ayrı evrimleşir, güven yok.

Neden: Test kodu gözden geçirmesi yapılmıyor, test refactoring'i ihmal ediliyor. Ders: Üretim kodu gibi test kodu'nu da care etmeliyiz.

BDD'nin Organizasyonel Faydası

BDD, teknik olmayan kişileri katmaya olanak sağlar:

Örnek: E-ticaret Ödeme Özelliği

Product Manager tarafından yazılmış senaryo, Credit Card Payment (Kredi Kartı Ödeme) özelliğini tanımlar. Senaryo şu şekilde yapılandırılmıştır: Müşteri sepetinde 100 dolar değerinde ürün varken, checkout'a gittiğinde, geçerli kart bilgilerini girer. Complete Payment butonuna tıklandığında, ödeme işlenir. Müşteri sipariş onayı alır. Envanter güncellenir.

Bu scenario'yu okuduğunda:

• Developer: "Ne implement ederim" anlar
• QA: "Ne test ederim" anlar
• Product Manager: "Özellik doğru şekilde kodlanmış mı" verify eder
• Business Analyst: "Requirement coverage" kontrol eder

Tek specification, hepsi anlar.

TDD/BDD Dönüşümünün Adımları

Aşama 1: Farkındalık (Ay 1)

• Workshop ve eğitim
• Örnek projeler
• Temel kavramları öğren

Aşama 2: Deneme (Ay 2-3)

• Pilot projesinde TDD dene
• Hataları, zorlukları yaşa
• Framework'leri coba

Aşama 3: Benimseme (Ay 4-6)

• Tüm ekibe extend et
• Best practices kurallarını koy
• Code review'da TDD kontrol et

Aşama 4: Mastery (Ay 6+)

• TDD, normal pratiğe dönüştü
• Refactoring confidence yüksek
• Teknik borç birikmiyor

Smart Maple TDD ve BDD Hizmetleri

Yazılım geliştirmeyi tasarımdan kaliteyle başlamak, TDD ve BDD yaklaşımlarıyla mümkün. Smart Maple, ekipleri TDD disiplinine geçişte danışmanlık, test framework kurulumu, Cucumber ve BDD uygulaması, ekip eğitimi ve coaching hizmetleri sunuyor. Test-driven geliştirme ile yazılım hatalarını tasarım aşamasında bularak, üretim sorunlarını önlemek için smart-maple.com adresini ziyaret edin ve deneyimli ekibimizle dönüşüm yolculuğunuzu başlatın.