Red-Green-Refactor pada satu aturan Product

1. Tiga langkah, tiga warna

Martin Fowler merangkum TDD menjadi tiga langkah yang "often summarized as Red - Green - Refactor". ^[4] Kent Beck, yang mempopulerkan TDD, menambahkan satu langkah di depan: tulis dulu test list, daftar skenario yang ingin Anda cakup, lalu ambil satu per satu. ^[3]

Jebakan yang paling sering: "The most common way that I hear to screw up TDD is neglecting the third step." ^[4] Green boleh "jelek" justru karena ada Refactor sesudahnya. Kalau Refactor dilewati, yang tersisa hanya kode jelek yang kebetulan ber-test.

2. Satu siklus: "harga harus lebih dari 0"

Test list untuk ProductService.CreateAsync (dari ROADMAP Hari 2): Product valid tersimpan, harga ≤ 0 ditolak, Stock negatif ditolak, nama duplikat ditolak. Kita ambil satu: harga ≤ 0 ditolak.

🔴 Red: tulis test, jalankan, lihat gagal

public class ProductServiceTests
{
    private readonly Mock<IProductRepository> _repo = new();
    private readonly ProductService _sut;

    public ProductServiceTests() => _sut = new ProductService(_repo.Object);

    [Theory]
    [InlineData(0)]
    [InlineData(-10)]
    public async Task CreateAsync_PriceNotPositive_ThrowsValidationException(decimal price)
    {
        // Arrange
        var request = new CreateProductRequest("Keyboard", price, 5, 1);

        // Act
        var act = () => _sut.CreateAsync(request);

        // Assert
        await Assert.ThrowsAsync<ValidationException>(act);
        _repo.Verify(r => r.AddAsync(It.IsAny<Product>()), Times.Never);
    }
}

dotnet test → merah: diharapkan ValidationException, tapi tidak ada exception yang dilempar. Itu gagal karena alasan yang benar: perilakunya memang belum ada. Tutorial xUnit Microsoft memakai pola yang sama: "With TDD, you write a test that's known to fail. Then you update the target code to make the test pass." ^[2]

🟢 Green: kode paling sederhana

public async Task<ProductResponse> CreateAsync(CreateProductRequest request)
{
    if (request.Price <= 0) throw new ValidationException("Price must be greater than 0.");
    // ... kode create dari siklus sebelumnya
}

"Using the TDD approach, write only enough code so this test passes." ^[2] dotnet test → test ini dan semua test lama hijau.

🔵 Refactor: rapikan, test tetap hijau

// Setelah siklus Stock dan nama duplikat menambah dua if lagi:
private async Task ValidateAsync(CreateProductRequest r)
{
    if (r.Price <= 0) throw new ValidationException("Price must be greater than 0.");
    if (r.Stock < 0) throw new ValidationException("Stock cannot be negative.");
    if (await _repo.ExistsByNameAsync(r.Name)) throw new ValidationException("Product name already exists.");
}

Refactor tidak menambah perilaku, jadi tidak ada test baru; jalankan test lagi dan pastikan semuanya tetap hijau. Lalu kembali ke test list dan ambil item berikutnya. ^[3]

3. Kenapa harus merah dulu?

Test yang belum pernah Anda lihat gagal belum terbukti bisa gagal. Beberapa cara sebuah test selalu hijau tanpa menguji apa pun: assertion terlupa, method yang salah dipanggil, atau mock yang membuat jalur error tidak pernah tersentuh. Beck mencatat dua versinya sebagai kesalahan: "write tests without assertions just to get code coverage" dan "delete assertions so the test pretends to pass." ^[3]

• Merah membuktikan test itu peka terhadap perilaku yang hendak Anda tambahkan. Hijau sesudahnya baru berarti sesuatu.
• Merah harus karena alasan yang benar. NullReferenceException dari setup yang rusak, atau error compile, bukan bukti apa pun tentang aturan harga. Perbaiki test-nya dulu.
• Untuk bug, urutannya sama. Fowler: tim yang sehat akan "write a test that exposes the bug, and only then to try to fix it." ^[6]

Padanan Node: menulis expect(...) di Jest lalu langsung melihat centang hijau tanpa pernah merah adalah sinyal yang sama. Curigai test-nya, bukan rayakan kodenya.

4. Arrange-Act-Assert dan nama test

Microsoft: "Arrange your objects, create, and configure them as necessary · Act on an object · Assert that something is as expected." Keuntungannya: "you can clearly separate what is being tested from the Arrange and Assert tasks." ^[1] Act cukup satu per test; kalau ada dua input, pakai parameterized test. ^[1] Jangan pula menaruh if/for di dalam test: "Avoid coding logic in unit tests." ^[1]

Kenapa nama itu penting: test adalah dokumentasi, dan "when tests fail, you can see exactly which scenarios don't meet your expectations." ^[1] Dari daftar nama test saja, pewawancara bisa membaca aturan bisnis Product Anda.

Ringkasan untuk dicetak: Reference: Red-Green-Refactor · Istilah: GLOSSARY.md

Ada yang belum jelas? Tanyakan ke saya (agent) di terminal, misalnya: "kalau refactor itu opsional menurut Beck, kapan saya boleh melewatinya?" atau "apa bedanya mock dan stub di test tadi?" (yang terakhir dibahas di lesson 0010).

Sumber: [1] Microsoft Learn: Unit testing best practices for .NET · [2] Microsoft Learn: Unit testing C# with xUnit · [3] Kent Beck: Canon TDD · [4] Martin Fowler: Test Driven Development · [5] Jest: test.each · [6] Martin Fowler: Self Testing Code