Memahami Test Pyramid: Fondasi Strategi Automated Testing

Membangun strategi testing yang robust dengan keseimbangan antara kecepatan, biaya, dan kepercayaan

Test Pyramid adalah salah satu konsep paling berpengaruh dalam software testing, namun sering disalahpahami atau diimplementasikan dengan buruk. Artikel ini memperkenalkan prinsip-prinsip fundamental test pyramid dan menjadi fondasi untuk memahami strategi automated testing modern. Kita akan eksplorasi apa itu test pyramid, mengapa penting, dan memberikan contoh praktis untuk memulai—menjadi dasar untuk eksplorasi lebih dalam tentang teknik testing lanjutan di artikel-artikel mendatang.

---

Apa Itu Test Pyramid?

Test Pyramid adalah strategi testing yang diperkenalkan oleh Mike Cohn dalam bukunya “Succeeding with Agile” (2009). Ini adalah metafora visual yang menunjukkan cara menyeimbangkan berbagai jenis automated test dalam software Anda.

Tiga Lapisan

        /\
       /  \
      /    \
     /  UI  \    ← Sedikit test, biaya tinggi, lambat
    /--------\
   /          \
  /Integration\  ← Test sedang, biaya sedang
 /--------------\
/                \
/   Unit Tests   \  ← Banyak test, biaya rendah, cepat
/------------------\

Lapisan Bawah - Unit Tests (70-80%)

• Test komponen individual secara terisolasi
• Eksekusi cepat (milidetik)
• Mudah maintenance
• Murah untuk ditulis dan dijalankan

Lapisan Tengah - Integration Tests (15-20%)

• Test interaksi antar komponen
• Waktu eksekusi sedang (detik)
• Lebih kompleks untuk di-maintain
• Biaya sedang

Lapisan Atas - E2E/UI Tests (5-10%)

• Test workflow user lengkap
• Eksekusi lambat (menit)
• Rapuh dan sulit di-maintain
• Mahal untuk ditulis dan dijalankan

---

Mengapa Bentuk Piramida?

Bentuk piramida sengaja dipilih dan merepresentasikan beberapa prinsip kunci:

1. Distribusi Test

Lebih banyak test di bawah, lebih sedikit di atas.

2. Kecepatan Eksekusi

Test cepat di bawah, lambat di atas.

3. Biaya Maintenance

Maintenance rendah di bawah, tinggi di atas.

4. Kecepatan Feedback

Feedback cepat di bawah, tertunda di atas.

5. Stabilitas Test

Test stabil di bawah, mudah gagal di atas.

---

Anti-Pattern: Ice Cream Cone

Banyak tim secara tidak sengaja membuat Ice Cream Cone:

/---------------\
\      UI      /   ← Lots of UI tests (WRONG!)
 \            /
  \ -------- /
   \  Int   /.     ← Few integration tests
    \      /
     \----/
      \U /         ← Very few unit tests
       \/

Masalah dengan Ice Cream Cone:

• ❌ Eksekusi test lambat (jam bukan menit)
• ❌ Test flaky yang gagal secara random
• ❌ Biaya maintenance tinggi
• ❌ Feedback terlambat
• ❌ Sulit debug kegagalan
• ❌ CI/CD pipeline mahal

---

Analisis Biaya per Lapisan Test

Mari kita breakdown biaya relatif dari setiap lapisan testing:

📊 Unit Tests

Faktor	Level Biaya	Detail
Pengembangan Awal	💰 Rendah	Cepat ditulis
Waktu Eksekusi	⚡ Sangat Cepat	1-10ms per test
Waktu CI/CD	⚡ Cepat	1-5 menit untuk 1000+ tests
Maintenance	💰 Rendah	Jarang rusak
Infrastruktur	💰 Minimal	Mesin lokal
Debugging	✅ Mudah	Langsung ketahuan
Biaya Tahunan	💰 Rendah	Overhead minimal

Contoh: Java/JUnit Unit Test

@Test
public void shouldCalculateTotalPrice() {
    // Given
    Product product = new Product("Laptop", 1000.0);
    Cart cart = new Cart();

    // When
    cart.addProduct(product, 2);
    double total = cart.calculateTotal();

    // Then
    assertEquals(2000.0, total);
}

// Eksekusi: 2ms ⚡
// Maintenance: Sekali per tahun 💰

📊 Integration Tests

Faktor	Level Biaya	Detail
Pengembangan Awal	💰💰 Sedang	Setup lebih kompleks
Waktu Eksekusi	⚡ Moderat	100ms-5s per test
Waktu CI/CD	⏱️ Moderat	10-30 menit untuk 200+ tests
Maintenance	💰💰 Sedang	Kadang rusak
Infrastruktur	💰💰 Sedang	DB, services diperlukan
Debugging	� Sedang	Perlu investigasi
Biaya Tahunan	💰💰 Sedang	Maintenance berkelanjutan

Contoh: Spring Boot Integration Test

@SpringBootTest
@AutoConfigureTestDatabase
public class OrderServiceIntegrationTest {

    @Autowired
    private OrderService orderService;

    @Autowired
    private OrderRepository orderRepository;

    @Test
    @Transactional
    public void shouldCreateOrderWithProducts() {
        // Given
        CreateOrderRequest request = new CreateOrderRequest(
            "CUST-001",
            List.of(
                new OrderItem("PROD-001", 2),
                new OrderItem("PROD-002", 1)
            )
        );

        // When
        Order order = orderService.createOrder(request);

        // Then
        assertNotNull(order.getId());
        assertEquals(3, order.getItems().size());

        // Verify database state
        Order savedOrder = orderRepository.findById(order.getId()).orElseThrow();
        assertEquals(OrderStatus.PENDING, savedOrder.getStatus());
    }
}

// Eksekusi: 1-2 detik ⚡
// Maintenance: Triwulan 💰💰

📊 E2E/UI Tests

Faktor	Level Biaya	Detail
Pengembangan Awal	💰💰💰 Tinggi	Skenario kompleks
Waktu Eksekusi	🐌 Lambat	10-60s per test
Waktu CI/CD	🐌 Sangat Lambat	1-3 jam untuk 100+ tests
Maintenance	💰💰💰 Tinggi	Sering rusak
Infrastruktur	💰💰💰 Mahal	Full stack + browsers
Debugging	❌ Sulit	Investigasi kompleks
Biaya Tahunan	💰💰💰 Tinggi	Overhead signifikan

Contoh: Playwright E2E Test

test("should complete checkout process", async ({ page }) => {
  // Given - User sudah login
  await page.goto("https://example.com/login");
  await page.fill("#email", "user@example.com");
  await page.fill("#password", "password123");
  await page.click('button[type="submit"]');

  // When - User menambah produk dan checkout
  await page.goto("https://example.com/products/laptop");
  await page.click('button:has-text("Add to Cart")');
  await page.click('a:has-text("Cart")');
  await page.click('button:has-text("Checkout")');

  // Isi informasi pengiriman
  await page.fill("#shipping-name", "John Doe");
  await page.fill("#shipping-address", "123 Main St");
  await page.fill("#shipping-city", "Jakarta");

  // Selesaikan pembayaran
  await page.fill("#card-number", "4242424242424242");
  await page.fill("#card-expiry", "12/25");
  await page.fill("#card-cvc", "123");
  await page.click('button:has-text("Place Order")');

  // Then - Order dikonfirmasi
  await expect(page.locator(".order-confirmation")).toBeVisible();
  await expect(page.locator(".order-number")).toContainText(/ORD-\d+/);
});

// Eksekusi: 30-45 detik 🐌
// Maintenance: Bulanan atau lebih 💰💰💰

💡 Ringkasan Perbandingan Biaya

Untuk aplikasi medium-sized yang umum:

Lapisan	Tests	Biaya Dev	Maintenance Tahunan	Dampak Keseluruhan
Unit	1,000	💰 Rendah	💰 Rendah	Minimal
Integration	200	💰💰 Sedang	💰💰 Sedang	Moderat
E2E	50	💰💰💰 Tinggi	💰💰💰 Tinggi	Signifikan
TOTAL	1,250	Beragam	Beragam	Seimbang

Insight Penting: E2E tests memerlukan resources jauh lebih besar dibanding unit tests baik untuk pengembangan maupun maintenance!

---

Implementasi Test Pyramid

Langkah 1: Mulai dengan Unit Tests

Fokuskan 70-80% effort testing di sini.

Apa yang Harus Ditest:

• Business logic
• Utility functions
• Perhitungan
• Validasi
• Domain models
• Value objects

Contoh: Testing Domain Entity

public class Order {
    private String id;
    private Customer customer;
    private List<OrderItem> items;
    private OrderStatus status;
    private Money total;

    public void addItem(Product product, int quantity) {
        if (status != OrderStatus.DRAFT) {
            throw new IllegalStateException("Tidak bisa modifikasi order yang sudah dikonfirmasi");
        }

        OrderItem item = new OrderItem(product, quantity);
        items.add(item);
        recalculateTotal();
    }

    public void confirm() {
        if (items.isEmpty()) {
            throw new IllegalStateException("Tidak bisa konfirmasi order kosong");
        }

        if (total.isGreaterThan(customer.getCreditLimit())) {
            throw new BusinessRuleException("Order melebihi limit kredit");
        }

        this.status = OrderStatus.CONFIRMED;
    }
}

// Unit tests
@Test
public void shouldNotAllowAddingItemsToConfirmedOrder() {
    Order order = new Order(customer);
    order.addItem(product, 1);
    order.confirm();

    assertThrows(IllegalStateException.class, () -> {
        order.addItem(anotherProduct, 1);
    });
}

@Test
public void shouldNotConfirmOrderExceedingCreditLimit() {
    Order order = new Order(customerWithLowCredit);
    order.addItem(expensiveProduct, 10);

    assertThrows(BusinessRuleException.class, () -> {
        order.confirm();
    });
}

Langkah 2: Tambahkan Integration Tests

Fokuskan 15-20% di sini. Test interaksi komponen.

Apa yang Harus Ditest:

• Operasi database
• API endpoints
• Integrasi external service
• Message queues
• Interaksi cache
• Operasi file

Contoh: Testing Repository Layer

@DataJpaTest
public class OrderRepositoryTest {

    @Autowired
    private OrderRepository orderRepository;

    @Autowired
    private TestEntityManager entityManager;

    @Test
    public void shouldFindOrdersByCustomerIdWithItems() {
        // Given
        Customer customer = entityManager.persist(new Customer("John Doe"));
        Product product = entityManager.persist(new Product("Laptop", 1000.0));

        Order order = new Order(customer);
        order.addItem(product, 2);
        entityManager.persist(order);
        entityManager.flush();

        // When
        List<Order> orders = orderRepository.findByCustomerId(customer.getId());

        // Then
        assertEquals(1, orders.size());
        assertEquals(2, orders.get(0).getItems().size());
    }
}

Langkah 3: E2E Tests Minimal

Fokuskan hanya 5-10% di sini. Test user journey kritis.

Apa yang Harus Ditest:

• Happy path untuk fitur kritis
• Registrasi dan login user
• Proses checkout
• Flow pembayaran
• Workflow bisnis inti

Kapan TIDAK test di level E2E:

• ❌ Error validasi (test di unit tests)
• ❌ Edge cases (test di unit tests)
• ❌ API error handling (test di integration tests)
• ❌ Database failures (test di integration tests)

---

Behavior-Driven Development (BDD) dengan Gherkin

Gherkin menyediakan bahasa umum antara developer, tester, dan stakeholder bisnis. Ini cocok sempurna dengan test pyramid!

Di Mana Gherkin Cocok

E2E Layer:     Gunakan skenario Gherkin → Selenium/Playwright
                 ↑
Integration:   Gunakan skenario Gherkin → API tests
                 ↑
Unit:          Gunakan plain unit tests (JUnit, dll.)

Sintaks Gherkin

Feature: Penarikan Rekening Bank
  Sebagai nasabah bank
  Saya ingin menarik uang dari rekening
  Agar saya bisa mendapat uang tunai

  Background:
    Given Saya punya rekening bank "ACC-001" dengan saldo Rp 10,000,000

  Scenario: Penarikan sukses dalam batas saldo
    When Saya menarik Rp 2,000,000 dari rekening
    Then Penarikan harus berhasil
    And Saldo rekening saya harus Rp 8,000,000
    And Saya harus menerima pesan konfirmasi

  Scenario: Penarikan gagal melebihi saldo
    When Saya menarik Rp 15,000,000 dari rekening
    Then Penarikan harus gagal
    And Saya harus melihat pesan error "Saldo tidak cukup"
    And Saldo rekening saya harus tetap Rp 10,000,000

  Scenario: Penarikan gagal dari rekening non-aktif
    Given Status rekening saya adalah "INACTIVE"
    When Saya menarik Rp 1,000,000 dari rekening
    Then Penarikan harus gagal
    And Saya harus melihat pesan error "Rekening tidak aktif"

  Scenario Outline: Multiple jumlah penarikan
    When Saya menarik Rp <jumlah> dari rekening
    Then Hasilnya harus "<hasil>"
    And Saldo saya harus Rp <saldo_akhir>

    Examples:
      | jumlah     | hasil  | saldo_akhir |
      | 1,000,000  | sukses | 9,000,000   |
      | 5,000,000  | sukses | 5,000,000   |
      | 10,000,000 | sukses | 0           |
      | 15,000,000 | gagal  | 10,000,000  |

Implementasi Gherkin dengan Cucumber (Java)

Step Definitions (Glue Code):

public class BankAccountSteps {

    private BankAccount account;
    private WithdrawalResult result;
    private Exception exception;

    @Given("Saya punya rekening bank {string} dengan saldo Rp {double}")
    public void sayaPunyaRekeningBankDenganSaldo(String accountNumber, double amount) {
        account = new BankAccount(accountNumber, Money.of(amount));
    }

    @Given("Status rekening saya adalah {string}")
    public void statusRekeningAdalah(String status) {
        account.setStatus(AccountStatus.valueOf(status));
    }

    @When("Saya menarik Rp {double} dari rekening")
    public void sayaMenarikDariRekening(double amount) {
        try {
            result = account.withdraw(Money.of(amount));
        } catch (Exception e) {
            exception = e;
        }
    }

    @Then("Penarikan harus berhasil")
    public void penarikanHarusBerhasil() {
        assertNotNull(result);
        assertTrue(result.isSuccess());
    }

    @Then("Penarikan harus gagal")
    public void penarikanHarusGagal() {
        assertNotNull(exception);
    }

    @Then("Saldo rekening saya harus Rp {double}")
    public void saldoRekeningHarus(double expectedBalance) {
        assertEquals(Money.of(expectedBalance), account.getBalance());
    }

    @Then("Saya harus melihat pesan error {string}")
    public void sayaHarusMelihatPesanError(String expectedMessage) {
        assertNotNull(exception);
        assertTrue(exception.getMessage().contains(expectedMessage));
    }
}

Gherkin untuk API Integration Tests

Feature: Order Management API
  Sebagai sistem e-commerce
  Saya ingin mengelola order melalui API
  Agar customer bisa menempatkan dan tracking order

  Scenario: Membuat order baru
    Given Saya terautentikasi sebagai customer "CUST-001"
    And Produk berikut ada:
      | id       | nama   | harga   |
      | PROD-001 | Laptop | 10000000|
      | PROD-002 | Mouse  | 500000  |
    When Saya POST ke "/api/orders" dengan body:
      """json
      {
        "customerId": "CUST-001",
        "items": [
          { "productId": "PROD-001", "quantity": 1 },
          { "productId": "PROD-002", "quantity": 2 }
        ]
      }
      """
    Then Response status harus 201
    And Response harus berisi:
      """json
      {
        "id": "${json-unit.any-string}",
        "customerId": "CUST-001",
        "status": "PENDING",
        "total": 11000000.0,
        "items": "${json-unit.any-array}"
      }
      """

Step Definitions:

public class OrderApiSteps {

    @Autowired
    private MockMvc mockMvc;

    private ResultActions lastResponse;

    @When("Saya POST ke {string} dengan body:")
    public void sayaPostDenganBody(String endpoint, String jsonBody) throws Exception {
        lastResponse = mockMvc.perform(
            post(endpoint)
                .contentType(MediaType.APPLICATION_JSON)
                .content(jsonBody)
        );
    }

    @Then("Response status harus {int}")
    public void responseStatusHarus(int expectedStatus) throws Exception {
        lastResponse.andExpect(status().is(expectedStatus));
    }

    @Then("Response harus berisi:")
    public void responseHarusBerisi(String expectedJson) throws Exception {
        lastResponse.andExpect(
            content().json(expectedJson, false)
        );
    }
}

Gherkin untuk E2E Tests

Feature: E-Commerce Checkout
  Sebagai customer
  Saya ingin menyelesaikan proses checkout
  Agar saya bisa membeli produk

  @e2e @smoke
  Scenario: Menyelesaikan checkout dengan kartu kredit
    Given Saya berada di homepage
    And Saya login sebagai "john.doe@example.com"
    When Saya navigasi ke produk "Gaming Laptop"
    And Saya klik "Tambah ke Keranjang"
    And Saya navigasi ke keranjang
    And Saya klik "Lanjutkan ke Checkout"
    And Saya isi informasi pengiriman:
      | Field   | Value          |
      | Nama    | John Doe       |
      | Alamat  | Jl. Sudirman 1 |
      | Kota    | Jakarta        |
      | Kode Pos| 12190          |
    And Saya pilih metode pembayaran "Kartu Kredit"
    And Saya isi detail kartu:
      | Field       | Value            |
      | Nomor Kartu | 4242424242424242 |
      | Expired     | 12/25            |
      | CVC         | 123              |
    And Saya klik "Buat Pesanan"
    Then Saya harus melihat "Pesanan Dikonfirmasi"
    And Saya harus melihat nomor order cocok "ORD-\d+"
    And Saya harus menerima email konfirmasi

---

Best Practices

1. Ikuti Aturan 70-15-5

• 70% Unit Tests
• 20% Integration Tests
• 10% E2E Tests

2. Test Hal yang Tepat di Level yang Tepat

❌ Jangan:

• Test logic validasi di E2E tests
• Test business rules di E2E tests
• Test UI behavior di unit tests

✅ Lakukan:

• Test business rules di unit tests
• Test API contracts di integration tests
• Test user journeys di E2E tests

3. Gunakan Test Doubles dengan Tepat

// Unit test: Gunakan mocks
@Test
public void shouldSendEmailWhenOrderConfirmed() {
    EmailService emailService = mock(EmailService.class);
    OrderService orderService = new OrderService(emailService);

    orderService.confirmOrder(order);

    verify(emailService).sendOrderConfirmation(order);
}

// Integration test: Gunakan database real
@Test
@Transactional
public void shouldPersistOrderWithItems() {
    Order order = orderService.createOrder(request);

    Order savedOrder = orderRepository.findById(order.getId()).orElseThrow();
    assertNotNull(savedOrder);
}

4. Buat Tests Cepat

// ✅ Unit test cepat
@Test
public void shouldCalculateDiscount() {
    assertEquals(100, calculator.calculateDiscount(1000, 10));
}
// Eksekusi: 2ms

// ❌ Test lambat (seharusnya integration test)
@Test
public void shouldCalculateDiscountFromDatabase() {
    Product product = productRepository.findById(1L);
    assertEquals(100, calculator.calculateDiscount(product));
}
// Eksekusi: 500ms

5. Jalankan Tests Berlapis

# CI/CD Pipeline stages

# Stage 1: Unit Tests (1-5 menit)
mvn test -Dtest=*UnitTest

# Stage 2: Integration Tests (5-15 menit)
mvn test -Dtest=*IntegrationTest

# Stage 3: E2E Tests (15-60 menit) - Hanya di main branch
npm run test:e2e

---

Kesalahan Umum yang Harus Dihindari

❌ Kesalahan 1: Testing Implementation Details

Buruk:

@Test
public void shouldCallRepositorySaveMethod() {
    service.createOrder(request);
    verify(repository).save(any(Order.class)); // Testing implementation!
}

Baik:

@Test
public void shouldReturnSavedOrderWithGeneratedId() {
    Order order = service.createOrder(request);
    assertNotNull(order.getId());
}

❌ Kesalahan 2: Terlalu Banyak E2E Tests

Jangan test setiap edge case dengan E2E tests!

Buruk: 50 skenario E2E covering semua validation errors

Baik: 5 skenario E2E untuk happy paths + unit tests untuk validasi

❌ Kesalahan 3: Mengabaikan Maintenance Test

Tests juga perlu refactoring!

// Buruk: Setup code yang duplikat
@Test
public void test1() {
    Product p = new Product();
    p.setName("Laptop");
    p.setPrice(1000.0);
    // ...
}

@Test
public void test2() {
    Product p = new Product();
    p.setName("Laptop");
    p.setPrice(1000.0);
    // ...
}

// Baik: Extract ke builder atau factory
@Test
public void test1() {
    Product laptop = ProductBuilder.aLaptop().build();
    // ...
}

@Test
public void test2() {
    Product laptop = ProductBuilder.aLaptop().build();
    // ...
}

---

Mengukur Kesuksesan

Metrik Kunci

1. Distribusi Test

   • Target: 70% unit, 20% integration, 10% E2E
   • Ukur: Hitung tests berdasarkan tipe

2. Waktu Eksekusi

   • Unit: < 10 menit
   • Integration: < 30 menit
   • E2E: < 60 menit

3. Code Coverage

   • Target: 80% overall
   • Unit: 85%+
   • Integration: 70%+

4. Flakiness Rate

   • Target: < 1%
   • Ukur: Failed tests / total runs

5. Biaya per Test

   • Track: Development + maintenance + infrastructure

---

Tools dan Framework

Unit Testing

• Java: JUnit 5, Mockito, AssertJ
• JavaScript: Jest, Vitest
• Python: pytest, unittest
• .NET: xUnit, NUnit, Moq

Integration Testing

• Java: Spring Boot Test, Testcontainers
• JavaScript: Supertest, Testing Library
• Database: H2, PostgreSQL dengan Docker

E2E Testing

• Playwright (recommended)
• Cypress
• Selenium WebDriver

BDD/Gherkin

• Cucumber (Java, JavaScript, Ruby)
• SpecFlow (.NET)
• Behave (Python)

---

Kesimpulan

Test Pyramid bukan hanya strategi testing—ini adalah strategi optimasi biaya yang memastikan:

✅ Loop feedback cepat

✅ Test suite yang maintainable

✅ Quality assurance yang cost-effective

✅ Kepercayaan dalam deployment

Poin-Poin Penting

1. Lebih banyak unit tests, lebih sedikit E2E tests - Lebih murah dan cepat
2. Test di level yang tepat - Jangan test business logic di E2E tests
3. Gunakan Gherkin untuk clarity - Jembatani gap antara bisnis dan tech
4. Ukur dan optimasi - Track biaya dan waktu eksekusi
5. Maintain tests Anda - Mereka juga production code

Ingat

“Test suite terbaik adalah yang berjalan cepat, gagal cepat, dan biaya maintenance rendah.” - Martin Fowler

Mulai dengan unit tests, tambahkan integration tests di mana diperlukan, dan gunakan E2E tests secara hemat untuk user journey kritis. Diri Anda di masa depan (dan budget Anda) akan berterima kasih! 🚀

---

Bacaan Lebih Lanjut

• Buku:

  • “Succeeding with Agile” oleh Mike Cohn
  • “Test-Driven Development” oleh Kent Beck
  • “Growing Object-Oriented Software, Guided by Tests” oleh Steve Freeman

• Artikel:

  • Martin Fowler - Test Pyramid
  • Google Testing Blog

• Video:

  • “Integration Tests are a Scam” oleh J.B. Rainsberger
  • “The Clean Code Talks” oleh Miško Hevery

---

Membangun software berkualitas adalah marathon, bukan sprint. Mulai dengan fondasi testing yang solid menggunakan pendekatan Test Pyramid, dan tim Anda akan deliver lebih cepat, dengan lebih percaya diri, dan dengan biaya lebih rendah.

Siap meningkatkan strategi testing Anda? Bergabunglah dengan training software engineering komprehensif kami di Kreasi Positif Indonesia!