TDD ve BDD tartışması genellikle bir taraf seçimi olarak çerçevelenir. Gerçekte farklı sorulara yanıt veriyorlar. Test odaklı geliştirme, kodun geliştiricinin amaçladığı şeyi yapıp yapmadığını sorarken davranış odaklı geliştirme, ekibin yazılımın ne yapması gerektiği konusunda hemfikir olup olmadığını sorar.

Farkı somutlaştırmak için her yaklaşımda küçük bir indirim özelliği oluşturuyoruz. Kodu Python 3.13’te standart kütüphaneyi kullanarak çalıştırdık ve aşağıdaki sonuçlar bu çalıştırmadan geldi. BDD kısmı mekanizmayı göstermek için kendimize ait küçük bir koşucu kullanır, bu nedenle gerçek bir proje Cucumber gibi bir araç kullanır veya onun yerine davranır.

Kısa cevap

Test odaklı geliştirme (TDD) bir kodlama uygulamasıdır. Başarısız olan küçük bir test yazarsınız, en basit kodla geçmesini sağlarsınız ve ardından tasarımı geliştirirsiniz. Testler kodla ve çoğunlukla geliştiriciler tarafından yazılır. Kent Beck uygulamayı popüler hale getirdi.

Davranış odaklı geliştirme (BDD), TDD’den doğan bir işbirliği uygulamasıdır ve Dan North bu terimi tanıttı. Geliştiriciler, test uzmanları ve iş adamları, sistemin nasıl davranması gerektiğine dair sade bir dille yazılmış örnekler üzerinde hemfikirdir ve bu örnekler daha sonra otomatikleştirilebilir.

TDD ve BDD yan yana

Özellik

Uygulayacağımız iş kuralı şu şekildedir: 1000 veya daha fazla siparişlerde %10 indirim uygulanır. Üyeler bu siparişlerde ekstra %5 indirim alır.

Bu kulağa çok açık gelebilir ama zaten belirsizdir. 500 harcayan üye %5 indirim alır mı? Cümlede “bu emirler” yazıyor, dolayısıyla öyle olmadığını varsayıyoruz. Bunu aklınızda bulundurun, çünkü bu tam olarak BDD’nin erken ortaya çıkarmak için tasarladığı türden bir sorudur.

TDD ile oluşturma

TDD, kırmızı, yeşil, yeniden düzenleme olarak bilinen kısa bir döngüyü takip eder:

Bunlar, her kural için bir tane içeren testlerimizdir:

class DiscountTests(unittest.TestCase):
    def test_no_discount_below_1000(self):
        self.assertEqual(discount(999, False), 0)

    def test_ten_percent_from_1000(self):
        self.assertEqual(discount(1000, False), 100)

    def test_member_gets_extra_five_percent(self):
        self.assertEqual(discount(1000, True), 150)

Daha sonra kodu üç aşamada yazdık ve her aşamadan sonra testleri çalıştırdık. Katı bir TDD oturumu her seferinde bir test ekler ve bu da aynı ilerlemeyi gösterir:

Aşama 1: en basit şey

def discount(total, is_member):
    return 0

# 3 tests, 2 failed
#   test_member_gets_extra_five_percent
#   test_ten_percent_from_1000

Sıfıra dönmek saçma görünebilir, ancak testlerin gerçekten başarısız olabileceğini ve geçtiği tek testin “indirim yok” kuralı olduğunu kanıtlar.

Aşama 2: eşiği ekleyin

def discount(total, is_member):
    if total >= 1000:
        return total * 0.1
    return 0

# 3 tests, 1 failed
#   test_member_gets_extra_five_percent

3. Aşama: Üye ekleyin ve temizleyin

def discount(total, is_member):
    rate = 0.1 if total >= 1000 else 0
    if is_member:
        rate += 0.05
    return round(total * rate, 2)

# 3 tests, 0 failed

Üçü de geçer. Ancak bu sürümü yakından okuyun. Bu, 500 dolar harcayan bir üyeye %5 indirim sağlıyor ki bu, kuralın kastettiğini varsaydığımız şey değildi. Bu durumu hiçbir test kapsamadı, dolayısıyla hiçbir şey onu işaretlemedi. TDD yalnızca test etmeyi düşündüğünüz davranışı korur. Bu gerçek bir sınırlamadır ve örneklerle ilgili konuşmaların bu kadar önemli olmasının nedeni budur.

Döngü neden önemlidir?

• Kırmızı, testin işe yaradığını kanıtlar. Hiç başarısız olmayan bir test, hiçbir şeyi test etmiyor olabilir.
• Yeşil odaklanmanızı sağlar. Yalnızca gereken kodu yazarsınız, bu da aşırı mühendisliğin önlenmesine yardımcı olur.
• Refactor kaliteyi yüksek tutar. Testler, tasarımı güvenli bir şekilde değiştirebilmeniz için size güven verir.
• Tasarımı etkiler. Test edilmesi zor olan kodlar genellikle çok sıkı bir şekilde bağlanmıştır ve bunu hemen fark edersiniz.

pytest eğiticimiz buna benzer testler yazmanın daha kullanışlı bir yolunu gösteriyor ve sınır değer analizi değer olarak neden 999 ve 1000’i seçtiğimizi açıklıyor.

BDD ile oluşturma

BDD araçlarla değil, bir konuşmayla başlar. Genellikle bu, bir ürün sorumlusunun, bir geliştiricinin ve bir test uzmanının somut örnekleri tartıştığı, üç dost olarak bilinen kısa bir toplantıdır:

Tester:  What about a member spending 500?
Product: Good question. No discount. It has to reach 1000 first.
Dev:     And exactly 1000 counts?
Product: Yes, 1000 or more.

Bu tek borsa sorunu TDD kodumuzda yakalayabilirdi. Daha sonra örneklerini Kornişon adı verilen yapılandırılmış bir formatta kaydederler:

Feature: Order discounts

  Scenario: Member reaches the discount threshold
    Given a member with a cart worth 1000
    When they view the amount to pay
    Then the amount to pay is 850

  Scenario: Member below the threshold gets no discount
    Given a member with a cart worth 500
    When they view the amount to pay
    Then the amount to pay is 500

Ekipteki herkes bunu okuyabilir ve “evet, bu doğru” veya “hayır, bu yanlış” diyebilir. Hiçbir zaman otomatikleştirmeseniz bile senaryo zaten faydalı işler yapmıştır.

Adımları koda bağlama

Araçlar, her düz dil satırını adım tanımı adı verilen bir işleve bağlar. Fikri göstermek için kendimiz küçük bir versiyon yazdık ve ilk senaryoyu uyguladık:

@step("a member with a cart worth 1000")
def given(ctx):
    ctx["cart"] = Cart(is_member=True)
    ctx["cart"].add(1000)

@step("they view the amount to pay")
def when(ctx):
    ctx["amount"] = ctx["cart"].payable()

@step("the amount to pay is 850")
def then(ctx):
    assert ctx["amount"] == 850

# ok Given a member with a cart worth 1000
# ok When they view the amount to pay
# ok Then the amount to pay is 850

Gerçek araçlar parametreler ekler, böylece tek bir adım hem “1000” hem de “500” ile eşleşebilir, artı raporlama da yapılabilir. Sonuç, yaşayan belgelerdir: gerçek olmayı bıraktığında yüksek sesle başarısız olan sistemin basit bir açıklaması.

İyi senaryolar yazmak

Tıklamaları ve alan kimliklerini açıklayan senaryolar her yeniden tasarımda bozulur ve iş dünyası okuyucuları bunları okumayı bırakır. Kullanıcı arayüzü ayrıntılarını adım kodunda tutun. Bu senaryolar, test senaryosu ve test senaryosu‘ndaki örneklerin yakın kuzenleridir ve sıklıkla kullanıcı kabul testinde de kullanılırlar.

Her ikisini bir arada kullanma

İkisi doğal olarak “dışarıdan içeriye” iş akışına uyar:

1. Ekip davranış üzerinde mutabakata varır ve bir BDD senaryosu yazar. Başarısız oldu çünkü henüz hiçbir şey yok.
2. Bir geliştirici, ihtiyaç duyulan küçük birimleri oluşturmak için TDD’yi kullanır.
3. Birim testleri geçer ve sonunda senaryo da geçer.
4. Her şey CI/CD ardışık düzeninizde çalışır.

Her birini doğru seviyede tutun. Önemli davranışlar için birkaç senaryonuz ve ayrıntılar için birçok hızlı birim testiniz olmalıdır. Birim ve entegrasyon testlerine ilişkin kılavuzumuz dengeyi kapsar.

Araçlar

Her biri ne zaman kullanılmalı

TDD şu durumlarda iyi uyum sağlar:

• Fiyatlandırma, ayrıştırma veya izinler gibi karmaşık mantıklar yazıyorsunuz.
• Bir hatayı düzeltiyorsunuz çünkü onu ilk önce başarısız bir testle yeniden oluşturabilirsiniz.
• Sık sık değişecek kod üzerinde çalışıyorsunuz.

BDD şu durumlarda iyi uyum sağlar:

• İş kuralları karmaşıktır ve yanlış anlamalar pahalıya mal olur.
• Teknik olmayan insanlar gerçekten senaryoları okuyup tartışacaklar.
• Birçok ekibin bir şeyin nasıl davrandığına ilişkin ortak bir tanıma ihtiyacı vardır.

Aşağıdaki durumlarda aşırıya kaçmak olabilir: tek kullanımlık bir prototip yazdığınızda veya belirsiz bir teknik fikri araştırdığınızda. Pek çok geliştirici önce yükselişe geçiyor, ardından testlerle yeniden yazıyor. Eğer mühendislik dışından hiç kimse senaryolara bakmayacaksa, BDD takımları da kötü bir yatırım olacaktır. Bu durumda iyi adlara sahip düz testler daha basittir.

Yaygın hatalar

• BDD’yi bir test aracı olarak ele almak. İşbirliği olmadan salatalık, testleri yazmanın ayrıntılı bir yoludur.
• TDD’de test uygulaması. Özel ayrıntılara bağlı testler, her yeniden düzenleme sırasında kesintiye uğrar.
• Yeniden düzenleme adımını atlamak. Karmaşık kodun yanı sıra testleri de geçersiniz.
• Koddan sonra testler yazmak ve buna TDD adını vermek. Bu yine de faydalıdır, ancak tasarım geri bildirimini kaybedersiniz.
• Çok fazla kullanıcı arayüzü senaryosu yazmak. Bunlar yavaş ve düzensiz hale geliyor. Bkz. kesintili testler.
• Yayın rakamlarının peşinde. Örneğimizin gösterdiği gibi, iyi bir haber hâlâ kimsenin dikkate almadığı davranışları gözden kaçırıyor.

Son sözler

TDD, doğru şeyi oluşturmanıza yardımcı olur ve BDD, doğru şeyi oluşturmanıza yardımcı olur. İndirim örneğimiz her iki tarafı da gösterdi: Kod tüm testlerden geçti, ancak basit bir konuşma yanlış bir varsayımı ortaya çıkardı. Bir sonraki küçük özelliğinizde deneyin. Herhangi bir koddan önce bir meslektaşınızla üç somut örnek yazın ve ardından her seferinde başarısız olan bir test oluşturun.

Sık sorulan sorular

Öğrenmeye devam et