TDD ve test yaklaşımları

TDD (Test-Driven Development, test güdümlü geliştirme), kodu yazmadan önce testi yazma yöntemidir. Örnekler saf bir fonksiyon üzerinden, ama döngü her kodda aynı. Bu rehber döngüyü, küçük bir örneği ve hangi testi yazacağınıza nasıl karar vereceğinizi anlatıyor.

Red-Green-Refactor

Martin Fowler'ın anlatımıyla TDD üç adımdan oluşur:¹

1. Red: Henüz var olmayan işlev için başarısız bir test yazın.

2. Green: Testi geçirecek kadar kod yazın.

3. Refactor: Yeni ve eski kodu düzenleyin, yapı temiz kalsın.

Fowler refactor adımını atlamayı TDD'nin en yaygın hatası olarak anıyor. Sonuç, dağınık kod parçalarından oluşan bir yığın oluyor.¹ Testi önce yazmanın bir faydası daha var: kodun uygulamasından önce arayüzünü düşünmek zorunda kalırsınız.¹

Refactoring'in kendisi Refactoring rehberinde.

Canon TDD

Kent Beck, TDD'nin adımlarını Canon TDD yazısında beş adımda topladı:²

Küçük bir örnek

Senaryo listesi: indirimsiz fiyat değişmez, %50 indirim fiyatı yarıya indirir.

// discount.test.ts
import { expect, test } from 'vitest'
import { applyDiscount } from './discount'

test('keeps the price without a discount', () => {
  expect(applyDiscount(100, 0)).toBe(100)
})

Red: applyDiscount henüz yok, test başarısız olur. Green: testi geçirecek en küçük kod:

// discount.ts
export const applyDiscount = (price: number, percent: number) => price

İkinci senaryoyu teste çevirin:

test('halves the price with a 50% discount', () => {
  expect(applyDiscount(100, 50)).toBe(50)
})

Test yine kırmızı. Şimdi gerçek mantığı yazın:

export const applyDiscount = (price: number, percent: number) =>
  price * (1 - percent / 100)

İki test de geçti. Refactor edilecek bir şey yok, bu adım isteğe bağlı.² Testleri çalıştırmak için:

$ pnpm dlx vitest run

Vitest vitest run testleri izleme moduna girmeden bir kez çalıştırır. Test dosyalarının adında .test. ya da .spec. geçmesi gerekir.³ Kurulum için Vitest Kurulum rehberine bakın.

Hangi testi yazmalı?

TDD'nin "nasıl" sorusunu cevapladık. "Hangi test" sorusu için Kent C. Dodds'ın Testing Trophy modeli var: statik, unit, entegrasyon ve uçtan uca (E2E) katmanları. Testlerden beklenen güven, harcanan zamana karşılık getirdiği değerdir.⁴ Dodds'a göre yatırımın büyük bölümü entegrasyon testlerine gitmeli, çünkü güven, hız ve maliyet dengesi orada en iyi.⁵

İlkesi şu: testleriniz yazılımın kullanılma biçimine ne kadar benzerse o kadar güven verir.⁴ Testing Library de aynı fikre dayanıyor: DOM düğümleriyle çalışır, component örneklerinin iç yapısına girmez.⁶ Testing Trophy'nin ayrıntısı Vitest rehberinde.

Sık yapılan hatalar

Beck'in uyardığı hatalardan seçmeler:²

• Assertion'sız test yazmak. Yalnızca kapsama yüzdesini artırır, hiçbir şeyi doğrulamaz.

• Tüm senaryoları baştan teste çevirmek. Hiçbiri geçmeden hepsini yazmak yerine birini yazıp geçirin.

• Testi geçirmek için assertion silmek. Testi gerçekten geçirin.

• Beklenen değeri kodun ürettiği değerden kopyalamak. Test, kodun ikinci bir kontrolü olmaktan çıkar.

• Testi geçirirken refactoring yapmak. İkisi ayrı adım.

• Erken soyutlamak. Tekrar bir ipucu, emir değil.

Ne zaman gerekmez?