Given-When-Then: apa itu, struktur skenario dan contoh

Apa itu Given-When-Then?

Given-When-Then — adalah pola deskripsi perilaku yang pertama kali dirumuskan oleh Dan North pada tahun 2006 sebagai bagian dari metodologi Behavior-Driven Development. Pola ini memecahkan masalah deskripsi skenario pengujian yang tidak terstruktur, yang sering kali berisi campuran prasyarat, tindakan, dan pemeriksaan dalam urutan sembarang.

Ide utama dari pola ini adalah pemisahan tanggung jawab antara tiga blok. Setiap blok bertanggung jawab atas tepat satu aspek skenario: keadaan sebelum, peristiwa selama, dan pemeriksaan setelah. Ini membuat skenario dapat dibaca, diverifikasi, dan diotomatisasi. Menurut penelitian pengembang framework Cucumber (2024), skenario yang secara ketat mengikuti pola Given-When-Then membutuhkan waktu 42% lebih sedikit untuk dipahami oleh anggota tim baru.

Asal-usul pola

Dan North meminjam ide struktur tiga bagian dari formulation of tests dalam TDD dan metodologi Test-by-Example (diciptakan oleh Brian Marick). Marick mengusulkan untuk mendeskripsikan persyaratan melalui contoh (examples) yang sekaligus berfungsi sebagai pengujian. Given-When-Then memformalkan ide ini, mengubah contoh yang tidak terstruktur menjadi pola yang dapat diulang.

Lingkup penerapan

Pola Given-When-Then diterapkan tidak hanya dalam skenario BDD di Gherkin, tetapi juga dalam pengujian unit biasa di JUnit, XCTest, dan framework lainnya. Komentar dalam kode yang membagi pengujian menjadi tiga blok adalah praktik umum untuk meningkatkan keterbacaan basis pengujian. Google merekomendasikan pendekatan ini dalam bukunya “Software Engineering at Google” (2020).

Struktur tiga blok

Setiap blok Given-When-Then memiliki semantik dan aturan pengisian yang ditentukan secara ketat. Pelanggaran terhadap aturan ini menyebabkan skenario yang sulit diotomatisasi atau dipahami.

Given: prasyarat

Blok Given mendeskripsikan keadaan sistem sebelum menjalankan tindakan yang diuji. Ini mencakup: objek yang ada (pengguna, pesanan, pengaturan), keadaan aktif (terautentikasi, terhubung ke jaringan), serta nilai awal data. Setiap Given harus dapat diverifikasi — jika keadaan sistem tidak sesuai dengan Given, skenario harus dilewati atau lingkungan pengujian harus dipersiapkan terlebih dahulu.

When: tindakan

Blok When mendeskripsikan satu peristiwa yang memulai perilaku yang diuji. Ini bisa berupa pemanggilan metode, penekanan tombol, penerimaan notifikasi atau respons dari server. Aturan kunci — satu When per skenario. Jika perlu memeriksa urutan tindakan, buatlah skenario terpisah, bukan rantai When.

// Given: membuat data pengujian
val user = User(email = "test@example.com", balance = 500.0)
val product = Product(price = 150.0)

// When: melakukan tindakan
val result = PurchaseUseCase().buy(user, product)

// Then: memeriksa hasil
assertEquals(PurchaseResult.Success, result)
assertEquals(350.0, user.balance)

Then: hasil yang diharapkan

Blok Then memeriksa apakah sistem telah beralih ke keadaan yang diharapkan. Ini mencakup: nilai yang dikembalikan, perubahan keadaan objek, pemanggilan layanan eksternal (melalui verifikasi mock), serta perubahan UI. Setiap blok Then dapat berisi beberapa pemeriksaan, tetapi semuanya merujuk pada satu tindakan.

Given-When-Then dan Arrange-Act-Assert

Given-When-Then dan Arrange-Act-Assert (AAA) — adalah dua varian dari pola tiga bagian yang sama, tetapi dengan audiens target yang berbeda. Memahami perbedaan mereka membantu memilih format yang tepat untuk tugas tertentu.

Kapan menggunakan Given-When-Then

Pola Given-When-Then optimal untuk skenario yang didiskusikan dengan klien atau analis: kriteria penerimaan fitur, skenario penggunaan, pemeriksaan regresi. Sintaks Gherkin memungkinkan penulisan skenario semacam itu tanpa pengetahuan pemrograman.

Kapan menggunakan Arrange-Act-Assert

Arrange-Act-Assert — adalah pilihan alami untuk pengujian unit yang memeriksa metode atau kelas tertentu. Format AAA tidak memerlukan framework tambahan dan bekerja di bahasa pemrograman apa pun. Untuk pengembangan iOS, Apple merekomendasikan AAA dalam dokumentasi XCTest (2024).

Contoh skenario di Kotlin

Mari kita lihat contoh praktis Given-When-Then di Kotlin untuk aplikasi Android. Contoh pertama — pengujian keranjang belanja menggunakan MockK. Contoh kedua — pengujian logika notifikasi push.

Contoh 1: keranjang belanja

class CartTest {
    fun `apply discount when total exceeds threshold`() {
        // Given
        val cart = Cart()
        cart.addItem(Item("Laptop", price = 1000.0))
        cart.addItem(Item("Mouse", price = 50.0))
        val discount = DiscountCalculator(0.1)

        // When
        val total = discount.applyIfEligible(cart)

        // Then
        assertEquals(945.0, total)
        assertTrue("Discount was not applied", total < 1050.0)
    }
}

Contoh 2: notifikasi push dengan coroutine

Contoh kedua mendemonstrasikan Given-When-Then dengan kode asinkron. Di sini Given menetapkan status Firebase Cloud Messaging, When — penerimaan notifikasi push, Then — pemeriksaan pemrosesan.

class PushNotificationTest {
    fun `handle push notification when app in background`() = runTest {
        // Given
        val prefs = mockk<SharedPreferences>()
        every { prefs.getString("token", null) } returns "fcm-token-abc"
        val handler = PushHandler(prefs)

        // When
        val data = RemoteMessage().apply {
            putData("type", "order_update")
            putData("order_id", "123")
        }
        val result = handler.handleNotification(data)

        // Then
        assertEquals(NotificationAction.OpenOrder("123"), result)
    }
}

Contoh 3: skenario Gherkin untuk otorisasi

Contoh ketiga — skenario BDD dalam Gherkin, yang menunjukkan Given-When-Then dalam konteks pengujian penerimaan:

Feature: User Authorization
  Scenario: User cannot login with expired token
    Given the user has an expired refresh token
    When they try to access the protected profile screen
    Then they should see the login screen
    And the app should clear all cached data

Praktik terbaik penulisan skenario

Penggunaan efektif Given-When-Then memerlukan kepatuhan terhadap beberapa praktik yang telah terbukti. Mereka memastikan keterbacaan, kemudahan pemeliharaan, dan kemampuan otomatisasi skenario.

Satu When per skenario

Aturan ketat: satu skenario — satu tindakan. Jika perlu memeriksa urutan beberapa When, buatlah beberapa skenario, di mana hasil sebelumnya menjadi prasyarat untuk yang berikutnya. Ini membuat skenario atomik dan mudah dipahami.

Hindari data spesifik di Given

Given harus mendeskripsikan esensi, bukan angka spesifik. Alih-alih “Given pengguna Ivanov dengan saldo 500 rubel” — “Given pengguna dengan saldo cukup”. Data spesifik dipindahkan ke Scenario Outline dengan tabel Examples. Ini membuat skenario universal dan dapat digunakan kembali.

• Tulis Then sebagai pernyataan yang terukur — “pengguna harus melihat layar login”, bukan “pengguna harus diarahkan”
• Gunakan And untuk langkah serupa — jika diperlukan beberapa Given, gabungkan melalui And, jangan buat Given kedua
• Jangan campur tingkat abstraksi — Given-When-Then harus berada pada satu level: bisnis atau teknis, bukan campuran
• Dokumentasikan alasan skenario — komentar di awal file .feature dengan deskripsi aturan bisnis membantu konteks

Given-When-Then dalam pipeline CI/CD

Integrasi skenario Given-When-Then ke dalam pipeline integrasi berkelanjutan mengubahnya dari dokumentasi menjadi perlindungan terhadap regresi. Setiap permintaan merge dalam proyek seluler secara otomatis menjalankan skenario BDD dan memblokir penggabungan jika setidaknya satu skenario gagal.

Menjalankan skenario secara otomatis

Skenario BDD di Cucumber untuk Android dijalankan melalui tugas Gradle ./gradlew cucumber. Untuk iOS (Quick/Nimble) — melalui xcodebuild test. Dalam sistem CI (GitHub Actions, GitLab CI, Bitrise) pengujian BDD dijalankan pada emulator atau perangkat nyata. Laporan dihasilkan dalam format HTML, yang dapat dipahami oleh manajer: skenario hijau — lulus, merah — gagal dengan indikasi langkah.

Dokumentasi hidup di repositori

File .feature disimpan di repositori di samping kode dan menjalani code review. Analis membuat permintaan merge dengan skenario baru sebelum dimulainya pengembangan (BDD-first). Pengembang menulis step definitions dan implementasi agar skenario ini menjadi hijau. Ketika semua skenario lulus — fungsionalitas siap. Pendekatan ini, yang dijelaskan dalam buku Gojko Adzic “Specification by Example” (2011), mengubah persyaratan menjadi artefak yang dapat dieksekusi.