Given-When-Then: nó là gì, cấu trúc kịch bản và ví dụ

Given-When-Then là gì?

Given-When-Then là một mẫu mô tả hành vi, được Dan North lần đầu tiên xây dựng vào năm 2006 như một phần của phương pháp Behavior-Driven Development. Mẫu này giải quyết vấn đề mô tả kịch bản kiểm thử không có cấu trúc, thường chứa hỗn hợp tiền điều kiện, hành động và xác minh theo thứ tự tùy ý.

Ý tưởng chính của mẫu là phân tách trách nhiệm giữa ba khối. Mỗi khối chịu trách nhiệm cho một khía cạnh của kịch bản: trạng thái trước, sự kiện trong và xác minh sau. Điều này làm cho kịch bản có thể đọc được, có thể xác minh và có thể tự động hóa. Theo một nghiên cứu của các nhà phát triển framework Cucumber (2024), các kịch bản tuân thủ nghiêm ngặt mẫu Given-When-Then giúp thành viên mới trong nhóm hiểu nhanh hơn 42%.

Nguồn gốc của mẫu

Dan North đã vay mượn ý tưởng cấu trúc ba phần từ công thức kiểm thử trong TDD và phương pháp Test-by-Example (do Brian Marick tạo ra). Marick đề xuất mô tả yêu cầu thông qua các ví dụ (examples) đồng thời đóng vai trò là kiểm thử. Given-When-Then đã chính thức hóa ý tưởng này, biến các ví dụ không có cấu trúc thành một mẫu có thể lặp lại.

Phạm vi áp dụng

Mẫu Given-When-Then không chỉ được áp dụng trong các kịch bản BDD với Gherkin, mà còn trong các kiểm thử đơn vị thông thường với JUnit, XCTest và các framework khác. Các chú thích trong mã nguồn chia kiểm thử thành ba khối là một thực hành phổ biến để cải thiện khả năng đọc của cơ sở kiểm thử. Google khuyến nghị cách tiếp cận này trong cuốn sách «Software Engineering at Google» (2020) của họ.

Cấu trúc ba khối

Mỗi khối của Given-When-Then có ngữ nghĩa được xác định chặt chẽ và các quy tắc điền nội dung. Vi phạm các quy tắc này dẫn đến các kịch bản khó tự động hóa hoặc hiểu.

Given: tiền điều kiện

Khối Given mô tả trạng thái của hệ thống trước khi thực hiện hành động được kiểm thử. Nó bao gồm: các đối tượng hiện có (người dùng, đơn hàng, cài đặt), trạng thái hoạt động (đã xác thực, kết nối mạng) và giá trị dữ liệu ban đầu. Mỗi Given phải có thể xác minh được — nếu trạng thái hệ thống không khớp với Given, kịch bản sẽ bị bỏ qua hoặc môi trường kiểm thử cần được chuẩn bị trước.

When: hành động

Khối When mô tả sự kiện duy nhất kích hoạt hành vi được kiểm thử. Đó có thể là một lời gọi phương thức, nhấp chuột, nhận thông báo hoặc phản hồi từ máy chủ. Quy tắc chính là một When cho mỗi kịch bản. Nếu cần xác minh một chuỗi hành động, hãy tạo các kịch bản riêng biệt, không phải một chuỗi When.

// Given: tạo dữ liệu kiểm thử
val user = User(email = "test@example.com", balance = 500.0)
val product = Product(price = 150.0)

// When: thực hiện hành động
val result = PurchaseUseCase().buy(user, product)

// Then: xác minh kết quả
assertEquals(PurchaseResult.Success, result)
assertEquals(350.0, user.balance)

Then: kết quả mong đợi

Khối Then xác minh rằng hệ thống đã chuyển sang trạng thái mong đợi. Điều này bao gồm: giá trị trả về, thay đổi trạng thái của đối tượng, lời gọi dịch vụ bên ngoài (thông qua xác minh mock) và thay đổi giao diện người dùng. Mỗi khối Then có thể chứa nhiều xác minh, nhưng tất cả đều liên quan đến một hành động duy nhất.

Given-When-Then và Arrange-Act-Assert

Given-When-Then và Arrange-Act-Assert (AAA) là hai biến thể của cùng một mẫu ba phần, nhưng với đối tượng mục tiêu khác nhau. Hiểu sự khác biệt của chúng giúp chọn định dạng phù hợp cho từng nhiệm vụ.

Khi nào sử dụng Given-When-Then

Mẫu Given-When-Then là tối ưu cho các kịch bản được thảo luận với khách hàng hoặc nhà phân tích: tiêu chí chấp nhận tính năng, trường hợp sử dụng, kiểm tra hồi quy. Cú pháp Gherkin cho phép viết các kịch bản này mà không cần kiến thức lập trình.

Khi nào sử dụng Arrange-Act-Assert

Arrange-Act-Assert là lựa chọn tự nhiên cho các kiểm thử đơn vị xác minh một phương thức hoặc lớp cụ thể. Định dạng AAA không yêu cầu framework bổ sung và hoạt động trong bất kỳ ngôn ngữ lập trình nào. Đối với phát triển iOS, Apple khuyến nghị AAA trong tài liệu XCTest (2024).

Ví dụ kịch bản bằng Kotlin

Hãy xem các ví dụ thực tế về Given-When-Then bằng Kotlin cho ứng dụng Android. Ví dụ đầu tiên là kiểm thử giỏ hàng sử dụng MockK. Ví dụ thứ hai là kiểm thử logic thông báo đẩy.

Ví dụ 1: giỏ hàng

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)
    }
}

Ví dụ 2: thông báo đẩy với coroutines

Ví dụ thứ hai minh họa Given-When-Then với mã bất đồng bộ. Ở đây Given thiết lập trạng thái Firebase Cloud Messaging, When — nhận thông báo đẩy, Then — xác minh xử lý.

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)
    }
}

Ví dụ 3: kịch bản Gherkin cho xác thực

Ví dụ thứ ba là kịch bản BDD bằng Gherkin thể hiện Given-When-Then trong bối cảnh kiểm thử chấp nhận:

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

Thực hành tốt nhất khi viết kịch bản

Áp dụng hiệu quả Given-When-Then yêu cầu tuân theo một số thực hành đã được kiểm chứng. Chúng đảm bảo khả năng đọc, bảo trì và tự động hóa của các kịch bản.

Một When cho mỗi kịch bản

Quy tắc nghiêm ngặt: một kịch bản — một hành động. Nếu cần xác minh một chuỗi nhiều When, hãy tạo nhiều kịch bản trong đó kết quả của kịch bản trước trở thành tiền điều kiện của kịch bản sau. Điều này làm cho kịch bản trở nên nguyên tử và dễ hiểu.

Tránh dữ liệu cụ thể trong Given

Given nên mô tả bản chất, không phải các con số cụ thể. Thay vì «Given người dùng Ivanov với số dư 500 rúp» — «Given người dùng có đủ số dư». Dữ liệu cụ thể được chuyển vào Scenario Outline với bảng Examples. Điều này làm cho kịch bản trở nên phổ quát và có thể tái sử dụng.

• Viết Then như các khẳng định có thể đo lường — «người dùng sẽ thấy màn hình đăng nhập», không phải «người dùng sẽ được chuyển hướng»
• Sử dụng And cho các bước cùng loại — nếu cần nhiều Given, hãy kết hợp chúng qua And, không tạo Given thứ hai
• Không trộn lẫn mức độ trừu tượng — Given-When-Then phải ở cùng một mức: hoặc kinh doanh, hoặc kỹ thuật, nhưng không phải hỗn hợp
• Ghi lại lý do của kịch bản — một chú thích ở đầu tệp .feature với mô tả quy tắc kinh doanh giúp ích cho bối cảnh

Given-When-Then trong pipeline CI/CD

Tích hợp các kịch bản Given-When-Then vào pipeline tích hợp liên tục biến chúng từ tài liệu thành công cụ bảo vệ chống hồi quy. Mỗi yêu cầu hợp nhất trong dự án di động tự động chạy các kịch bản BDD và chặn hợp nhất nếu ít nhất một kịch bản thất bại.

Chạy tự động các kịch bản

Các kịch bản BDD với Cucumber cho Android được chạy thông qua tác vụ Gradle ./gradlew cucumber. Cho iOS (Quick/Nimble) — thông qua xcodebuild test. Trong các hệ thống CI (GitHub Actions, GitLab CI, Bitrise), các kiểm thử BDD được thực thi trên trình giả lập hoặc thiết bị thật. Báo cáo được tạo ở định dạng HTML dễ hiểu cho quản lý: kịch bản xanh — đạt, đỏ — thất bại có chỉ dẫn bước.

Tài liệu sống trong kho lưu trữ

Các tệp .feature được lưu trữ trong kho lưu trữ bên cạnh mã nguồn và trải qua đánh giá mã. Nhà phân tích tạo yêu cầu hợp nhất với các kịch bản mới trước khi bắt đầu phát triển (BDD-first). Nhà phát triển viết định nghĩa bước và triển khai để các kịch bản này trở nên xanh. Khi tất cả kịch bản đều đạt — chức năng đã sẵn sàng. Cách tiếp cận này, được mô tả trong cuốn sách của Gojko Adzic «Specification by Example» (2011), biến yêu cầu thành một tạo phẩm có thể thực thi.