Jenis test dan test double untuk Product Catalog

1. Tiga jenis test, satu piramida

Microsoft: "Unit tests are used to test isolated software components, such as individual class methods. Integration tests confirm that two or more app components work together to produce an expected result, possibly including every component required to fully process a request." ^[1] Integration test biasanya menyentuh "Database · File system · Network appliances · Request-response pipeline". ^[1]

Testing pyramid menurut Ham Vocke (artikel di martinfowler.com) punya dua aturan: "Write tests with different granularity" dan "The more high-level you get the fewer tests you should have." ^[4] Microsoft bahkan memberi aturan praktis: "If a behavior can be tested using either a unit test or an integration test, choose the unit test." ^[1] Jadi aturan harga ≤ 0 cukup di unit test (lesson 0009); integration test cukup membuktikan bahwa request yang salah benar-benar berakhir sebagai 400.

Di GLOSSARY: Integration Test = API sungguhan lewat WebApplicationFactory; bukan E2E (yang dari browser sampai DB). Pewawancara sering sengaja mencampur dua istilah ini.

2. Mock, stub, fake: semuanya test double

"Test Double is a generic term for any case where you replace a production object for testing purposes." ^[3] Bedanya ada di peran objek itu dalam test:

Kalimat kunci untuk interview: "only mocks insist upon behavior verification. The other doubles can, and usually do, use state verification." ^[5] Microsoft merangkumnya: "You run Assert operations against a mock object, but not against a stub." ^[2]

Jebakan istilah: objek new Mock<IProductRepository>() dari Moq ^[6] belum tentu mock. Kalau Anda hanya memakai Setup/Returns dan tidak pernah Verify, perannya stub. Microsoft juga mencatat bahwa dokumentasi .NET memakai "fake" sebagai istilah umum ("a fake can be a stub or a mock"), sementara Fowler/Meszaros memakainya lebih sempit. ^[2] Di interview, sebut definisi Fowler lalu tambahkan catatan ini: itu tanda Anda paham, bukan hafal.

3. WebApplicationFactory: menguji API tanpa deploy

"ASP.NET Core supports integration tests using a unit test framework with a test web host and an in-memory test server." WebApplicationFactory<TEntryPoint> "is used to create a TestServer for the integration tests. TEntryPoint is the entry point class of the SUT, usually Program.cs." ^[1] Ia ada di paket Microsoft.AspNetCore.Mvc.Testing (sudah ada di setup ROADMAP).

// Program.cs (paling bawah): class Program implisit dibuat public supaya bisa jadi TEntryPoint
public partial class Program { }

// Test project
public class ApiFactory : WebApplicationFactory<Program>
{
    protected override void ConfigureWebHost(IWebHostBuilder builder) =>
        builder.ConfigureServices(services =>
        {
            // dijalankan SETELAH Program.cs: hapus DbContext SQL Server, daftarkan SQLite in-memory (fake)
        });
}

public class ProductsApiTests(ApiFactory factory) : IClassFixture<ApiFactory>
{
    [Fact]
    public async Task Post_InvalidPrice_Returns400()
    {
        var client = factory.CreateClient();                         // Arrange: HttpClient ke TestServer
        var response = await client.PostAsJsonAsync("/api/products",
            new CreateProductRequest("Mouse", 0, 1, 1));             // Act: request HTTP sungguhan, in-memory
        Assert.Equal(HttpStatusCode.BadRequest, response.StatusCode); // Assert: status code
    }
}

• Kenapa public partial class Program? Microsoft: "Expose the implicitly defined Program class to the test project", lewat InternalsVisibleTo atau partial class public. ^[1]
• Kenapa penggantian DbContext berhasil? "The test app's builder.ConfigureServices callback is executed after the app's Program.cs code is executed." ^[1]
• Ganti satu service untuk satu test saja: factory.WithWebHostBuilder(b => b.ConfigureTestServices(...)). ^[1]
• IClassFixture berbagi satu factory untuk semua test di class itu ("provide shared object instances across the tests in the class"). ^[1]

Padanan Node: Supertest, request(app).post("/api/products"). Supertest juga tidak butuh server yang sudah listen: "if the server is not already listening for connections then it is bound to an ephemeral port for you". ^[8] Bedanya, TestServer bahkan tidak membuka port; semuanya in-memory.

4. Apa yang di-mock, apa yang tidak

Untuk database di integration test, dokumentasi EF Core punya urutan saran yang jelas: utamakan database produksi asli (mis. lewat Testcontainers); kalau butuh test double, repository pattern; kalau tidak bisa, SQLite in-memory. Provider EF Core in-memory "is highly discouraged". ^[9] ROADMAP memakai SQLite karena cepat disiapkan; trade-off-nya: "testing against SQLite does not guarantee the same results as against SQL Server" (mis. SQLite case-sensitive, SQL Server tidak). ^[9] Menyebut trade-off ini di interview langsung terdengar mid-level.

Ini juga menyambung ke lesson 0011: salah satu argumen pro Repository di atas EF Core adalah kemudahan di-mock, dan dokumentasi EF Core sendiri menyebutnya "the only approach allowing the comprehensive and reliable stubbing/mocking of the data layer", dengan "significant cost". ^[9]

Ringkasan untuk dicetak: Reference: Jenis test dan test double · Siklus TDD: Reference: Red-Green-Refactor · Istilah: GLOSSARY.md

Ada yang belum jelas? Tanyakan ke saya (agent) di terminal, misalnya: "kapan saya pakai ConfigureTestServices dibanding ConfigureServices?" atau "bagaimana Testcontainers dipasang di ApiFactory?"

Sumber: [1] Microsoft Learn: Integration tests in ASP.NET Core · [2] Microsoft Learn: Unit testing best practices for .NET · [3] Martin Fowler: TestDouble · [4] Ham Vocke (martinfowler.com): The Practical Test Pyramid · [5] Martin Fowler: Mocks Aren't Stubs · [6] Moq Quickstart · [7] Jest: Mock Functions · [8] SuperTest · [9] Microsoft Learn: EF Core, Choosing a testing strategy