Behavior-Driven Development mı, Test-Driven Development mı? Farklar ve Birlikte Kullanım

Ortak kök: testi işin başına almak

TDD (Test-Driven Development, teste dayalı geliştirme) ve BDD (Behavior-Driven Development, davranışa dayalı geliştirme), testi kod yazıldıktan sonra yapılan bir kontrol olmaktan çıkarıp geliştirmenin yönlendiricisi hâline getiren iki yaklaşımdır. TDD, Kent Beck tarafından Extreme Programming'in bir parçası olarak geliştirildi. BDD ise TDD'den doğdu ve odağı "kod doğru çalışıyor mu" sorusundan "sistem iş açısından doğru davranıyor mu" sorusuna genişletti.

İki yaklaşımda da çalışan bir örnek, kodun ne yapması gerektiğini tarif eder ve kod bu örneği karşılayacak kadar yazılır. Fark, örneğin kim tarafından, hangi dilde ve hangi ölçekte yazıldığındadır. TDD geliştiricinin kod tasarımı için kullandığı bir tekniktir; BDD ise iş birimi, test ve geliştirme arasında ortak anlayış kuran bir ekip çalışma biçimidir.

Ölçüt ölçüt temel farklar

• Temel soru: BDD / doğru şeyi mi yapıyoruz, sistem iş açısından beklenen davranışı gösteriyor mu? TDD / şeyi doğru mu yapıyoruz, kod tasarımı sağlam ve test edilebilir mi?
• Katılımcılar: BDD / ürün sahibi ya da iş analisti, test uzmanı ve geliştirici birlikte çalışır. TDD / ağırlıklı olarak geliştirici tek başına ya da eşli programlamada uygular.
• Dil: BDD / örnekler iş dilinde, çoğunlukla Gherkin söz dizimiyle Given/When/Then adımlarıyla yazılır. TDD / testler programlama dilinde, birim test çerçeveleriyle yazılır.
• Ölçek: BDD / bir kullanıcı hikâyesinin ya da özelliğin dışarıdan görünen davranışı. TDD / tek bir fonksiyonun, sınıfın ya da küçük bir birimin davranışı.
• Döngü: BDD / keşif, formülasyon ve otomasyon pratikleri. TDD / kırmızı, yeşil ve yeniden düzenleme (red, green, refactor) adımları.
• Ortaya çıkan çıktı: BDD / sistem davranışını anlatan ve otomatik olarak doğrulanan yaşayan dokümantasyon. TDD / kendini test eden kod ve sürekli yeniden düzenlenen temiz bir tasarım.
• Tipik araçlar: BDD / Cucumber; .NET projelerinde, desteği sona eren SpecFlow'un yerini alan ve onun kod tabanından türeyen Reqnroll. TDD / JUnit, NUnit, pytest, Jest gibi birim test çerçeveleri.

TDD döngüsü nasıl işler?

Martin Fowler'ın özetiyle TDD, art arda tekrarlanan basit adımlardan oluşur: eklenecek bir sonraki işlev parçası için bir test yazılır, test geçene kadar işlevsel kod yazılır, ardından hem yeni hem eski kod iyi yapılandırılmış hâle gelecek şekilde yeniden düzenlenir. Bu adımlar kırmızı, yeşil ve yeniden düzenleme olarak özetlenir. Fowler, döngüden önce test senaryolarının bir listesini çıkarmanın da önemli bir başlangıç adımı olduğunu, testleri doğru sıralamanın ayrı bir beceri olduğunu vurgular.

TDD'nin en sık yanlış uygulandığı nokta üçüncü adımın atlanmasıdır. Yeniden düzenleme yapılmadığında testleri olan ama dağınık bir kod parçaları yığını ortaya çıkar. Testi önce yazmanın iki kazancı vardır: kod baştan test edilebilir yazılır ve geliştirici önce arayüzü, yani kodun nasıl kullanılacağını düşünmek zorunda kalır.

BDD pratikleri: keşif, formülasyon, otomasyon

Cucumber'ın tanımıyla BDD, iş insanları ile teknik insanlar arasındaki boşluğu kapatan bir çalışma biçimidir. Gündelik BDD çalışması yinelemeli bir süreçtir. Keşif (Discovery) aşamasında küçük bir değişiklik, örneğin bir kullanıcı hikâyesi ele alınır ve beklenen davranış somut örneklerle konuşulup netleştirilir. Formülasyon (Formulation) aşamasında bu örnekler otomatikleştirilebilecek biçimde yazılır ve ekip üzerinde uzlaşır. Otomasyon (Automation) aşamasında her örnekle tarif edilen davranış, önce otomatik bir testle başlanarak uygulanır.

BDD mevcut çevik süreci değiştirmez, onu güçlendirir. Asıl değer, kodlama başlamadan önce yapılan konuşmalarda üretilir: belirsiz bir kural, kenar durumu ya da çelişkili beklenti somut bir örnek üzerinde tartışılırken ortaya çıkar. Gherkin dosyaları bu konuşmaların kalıcı kaydı ve sistemin davranışına karşı sürekli doğrulanan dokümantasyonu olur.

Örnek: aynı özellik, iki düzeyde

Örneğin bir e-ticaret ekibi "sadakat üyelerine kargo ücretsizdir" kuralını geliştiriyor. BDD keşif oturumunda ürün sahibi, test uzmanı ve geliştirici örnekleri konuşur: üyelik süresi dolmuş bir müşteri ne görür, sepette indirimli ürün varsa kural değişir mi? Bu örnekler Türkçe anahtar kelimelerle Gherkin senaryosu olarak yazılır: "Diyelim ki sadakat üyesi bir müşteri var, Eğer ki müşteri sepeti onaylarsa, O zaman kargo ücreti sıfır gösterilir." Dosyanın başındaki dil bildirimi (# language: tr) Cucumber'a bu anahtar kelimelerin Türkçe olduğunu söyler.

Geliştirici senaryoyu çalıştırır, senaryo başarısız olur. Ardından kargo hesaplayan sınıfa inip TDD döngüsüne girer: üyelik durumu, sepet içeriği ve kampanya kuralları için birim testlerini tek tek yazar, her testi geçirecek kodu ekler ve yeniden düzenler. Birim testleri yeşile döndüğünde dıştaki BDD senaryosu da geçer. Bu dıştan içe çalışma biçiminde BDD özelliğin doğru olduğunu, TDD ise kodun sağlam olduğunu güvenceye alır.

Hangi durumda hangisi öne çıkar?

BDD öne çıkar: • İş kuralları karmaşık, yoruma açık ve sık değişiyorsa. • İş birimi ile yazılım ekibi arasında yanlış anlaşılmalar, yeniden yapılan işler ve kabul aşamasında çıkan sürprizler sık yaşanıyorsa. • Düzenlemeye tabi sektörlerde davranışın okunabilir ve doğrulanmış bir kaydına ihtiyaç varsa.

TDD öne çıkar: • Algoritma, hesaplama ve veri dönüştürme gibi mantığı yoğun kod yazılıyorsa. • Kod sık yeniden düzenleniyor ve güvenli değişiklik için hızlı geri bildirim gerekiyorsa. • Kütüphane, API ya da altyapı bileşeni gibi doğrudan iş kullanıcısına dokunmayan kod geliştiriliyorsa.

İki yaklaşım rakip değildir. Birlikte uygulandıklarında BDD dış döngüde neyin yapılacağını, TDD iç döngüde nasıl yapılacağını yönetir.

Sık yapılan hatalar

• BDD'yi yalnız Cucumber kullanmak sanmak; konuşma ve keşif olmadan yazılan Gherkin dosyaları yalnızca okunması zor test betikleri olur.
• Gherkin senaryolarını "butona tıkla, alana yaz" gibi arayüz adımlarıyla doldurmak; senaryolar arayüz değil davranış anlatmalıdır.
• TDD'de yeniden düzenleme adımını atlamak.
• TDD'yi yüksek kapsama oranı hedefiyle karıştırmak; amaç oran değil, tasarımı test yoluyla yönlendirmektir.
• Her senaryoyu uçtan uca arayüz testiyle otomatikleştirmek; BDD senaryoları çoğu zaman servis ya da alan katmanında daha hızlı ve kararlı çalıştırılabilir.

Mindset programlarında BDD ve TDD

Behavior-Driven Development (BDD) ve Cucumber eğitimi BDD yaklaşımı ve ortak dil, Gherkin ile senaryo yazımı, adım tanımları ve otomasyon katmanı ile bakım, raporlama ve ekip pratiklerini işler. Test Driven Development (TDD) ve Unit Testing Uzmanlığı Eğitimi ise TDD temelleri, unit testing temelleri, mocking ve test izolasyonu, test kapsamı ve TDD ile güvenli yeniden düzenleme başlıklarını kapsar.

Kabul testine dayalı geliştirmeyi mimari ve kurumsal test stratejisiyle birlikte ele almak isteyenler için Yazılım Mimarisi ATDD ve Test Stratejisi eğitimi tamamlayıcıdır.