TDD — Red, Green, Refactor

Bazı yazılımcıların tuhaf bir alışkanlığı var: kodu yazmadan önce onu sınayacak testi yazarlar. Sebebini bilmezsen bu bir ritüele dönüşür, o yüzden önce sebebe bakalım.

Kırmızı adım neyi kanıtlar?

Testi önce kırmızı görmek, aradaki farkı gösteren tek kanıttır. Kırmızıdan yeşile geçişi izlediğinde, o testin gerçekten o davranışa bağlı olduğunu bilirsin.

Kendin gör

Aşağıdaki kata kendi kendine doğru döngüyü işletiyor. Önce temiz bir tur izle, sonra kırmızı düğmelerle kısayolları dene ve Suite güveni çubuğuna ne olduğuna bak.

// henüz kod yok

Üç kısayol, üç farklı kayıp:

• Önce kodu yaz — test yazıldığı anda yeşil. Suite dolu görünüyor ama o test hiçbir zaman bir hatayı yakalayacağını kanıtlamadı. En sinsi olanı bu: hiçbir alarm çalmaz.
• Hepsini bir anda yaz — kalan bütün testler yazıldıkları anda yeşil oluyor. Suite güveni çöküyor. Coverage aracı bunu %100 gösterir.
• Kırmızıyken refactor et — davranışı değiştirmediğini doğrulayacak hiçbir şey yok, çünkü suite zaten kırmızı.

Bir de üçgenleme adımına dikkat et: fizzBuzz(6) == "Fizz" testi yazıldığı anda geçiyor ve bu beklenen davranış. Simülatör bunu ihlal olarak saymıyor, çünkü amacı yeni davranış sürüklemek değil, mevcut genellemeyi doğrulamak.

Üç adımın her birinin işi ayrı

En çok atlanan adım refactor. Atlanınca geriye kalan şey test-first geliştirmedir; işe yarar ama TDD’nin tasarım faydasının tamamı o üçüncü adımdadır.

Green adımında “aptal” kod yazmak normaldir.

1
String fizzBuzz(int n) {
2
    return "1";          // evet, gerçekten böyle yazılır
3
}

Bu kasıtlıdır. Genelleme, bir sonraki kırmızı testin zorlamasıyla gelir:

1
assertEquals("2", fizzBuzz(2));   // "1" döndüren kod artık yetmiyor
2

3
String fizzBuzz(int n) {
4
    return String.valueOf(n);     // genelleme, tahminle değil baskıyla geldi
5
}

Buna üçgenleme (triangulation) denir. Fazladan yazdığın her satır, hiçbir testin talep etmediği koddur — ve hiçbir testin talep etmediği kod, hiçbir testin korumadığı koddur.

Aynı döngüyü bir bankanın havale ekranındaki IBAN kontrolünde izleyebilirsin. Testler yazıldıkları sırayla duruyor; sonuncusu bir müşterinin bildiriminden doğdu.

1
// Tests in the order they were written; each one was seen red before its code existed.
2
class IbanValidatorTest {
3

4
    private final IbanValidator validator = new IbanValidator();
5

6
    @Test   // 1. Red: IbanValidator did not exist. Green: return true.
7
    void acceptsAValidTurkishIban() {
8
        assertThat(validator.isValid("TR330006100519786457841326")).isTrue();
9
    }
10

11
    @Test   // 2. Red: "return true" accepts anything. Green: check the length.
12
    void rejectsAWrongLength() {
13
        assertThat(validator.isValid("TR3300061005197864578413")).isFalse();
14
    }
15

16
    @Test   // 3. Red: a typo has the right length. Green: the mod-97 checksum.
17
    void rejectsATypoInTheAccountNumber() {
18
        assertThat(validator.isValid("TR330006100519786457841327")).isFalse();
19
    }
20

21
    @Test   // 4. Triangulation: green at once, and that is expected.
22
    void acceptsAnotherValidIban() {
23
        assertThat(validator.isValid("TR360001000123456789012345")).isTrue();
24
    }
25
}

1
// Customer report: "My IBAN is rejected when I paste it from my bank's app."
2
// The app copies it in groups of four. This test came first and went red.
3
class IbanWithSpacesTest {
4

5
    @Test
6
    void acceptsAnIbanWrittenInGroupsOfFour() {
7
        assertThat(new IbanValidator().isValid("TR33 0006 1005 1978 6457 8413 26")).isTrue();
8
    }
9
}

1
// Turkish IBANs: "TR", two check digits and 22 digits, verified with the ISO 13616 mod-97 check.
2
final class IbanValidator {
3

4
    private static final Pattern TURKISH_IBAN = Pattern.compile("TR\\d{24}");
5

6
    boolean isValid(String input) {
7
        String iban = input.replace(" ", "");
8
        return TURKISH_IBAN.matcher(iban).matches() && mod97(iban) == 1;
9
    }
10

11
    // Move the first four characters to the end, read letters as numbers (A=10 ... Z=35)
12
    // and keep only the remainder, so the huge number is never built.
13
    private static int mod97(String iban) {
14
        String rearranged = iban.substring(4) + iban.substring(0, 4);
15
        int remainder = 0;
16
        for (char c : rearranged.toCharArray()) {
17
            int value = Character.getNumericValue(c);
18
            remainder = (value > 9 ? remainder * 100 : remainder * 10) + value;
19
            remainder %= 97;
20
        }
21
        return remainder;
22
    }
23
}

Coverage yalan söyler, mutasyon testi söylemez

Test coverage?Terimin tanımını açcoverageTestler sırasında çalıştırılan kod oranı. Kodun doğrulandığını değil, yalnızca çalıştırıldığını gösterir — assertion içermeyen bir test de coverage üretir.Sözlükte gör → yalnızca “bu satır çalıştı mı” sorusunu ölçer. Şu test %100 coverage üretir ve hiçbir şey doğrulamaz:

1
@Test
2
void fizzBuzzCalisir() {
3
    fizzBuzz(15);        // assertion yok — satır çalıştı, coverage sayıldı
4
}

Mutasyon testi doğru soruyu sorar: kodu kasten bozarsam testler bunu yakalar mı? PIT gibi araçlar > işaretini >= yapar, bir return değerini değiştirir, bir if’i ters çevirir — ve hiçbir testin kırmızıya dönmediği her mutasyon?Terimin tanımını açmutasyon testiKodu kasten bozup testlerin fark edip etmediğini ölçer. Coverage'ın cevaplayamadığı asıl soruyu sorar: bu testler gerçekten bir şey koruyor mu?Sözlükte gör →u rapor eder.

mvn org.pitest:pitest-maven:mutationCoverage
# Çıktı: mutation score — coverage'dan çok daha dürüst bir sayı

Simülatördeki suite güveni çubuğu kabaca bu fikri gösterir: kaç test gerçekten bir şeyi kanıtladı.

Tuzaklar: TDD her yerde gerekmez

Sınırlarını bilmek, yöntemi savunmaktan daha değerli:

• İyi uyduğu yerler: net girdi/çıktı olan iş kuralları, hata düzeltme (önce hatayı gösteren kırmızı test), algoritmalar, refactor güvenlik ağı.
• Kötü uyduğu yerler: henüz nasıl görüneceğini bilmediğin keşifsel UI çalışması, atılacak prototipler, ağır dış bağımlılık içeren entegrasyon noktaları.

Bir hata bildirimi geldiğinde ise TDD neredeyse her zaman doğru araçtır: önce hatayı yeniden üreten kırmızı testi yaz. Böylece hem düzelttiğini kanıtlamış hem de aynı hatanın geri gelmesini engellemiş olursun.

Kendini sına