BDD: khái niệm, kịch bản hành vi và framework

BDD là gì?

Behavior-Driven Development là sự tiến hóa của TDD do Dan North đề xuất năm 2006 như một câu trả lời cho vấn đề công thức hóa kiểm thử. Trong TDD, nhà phát triển viết một bài kiểm tra, nhưng câu hỏi “chính xác thì kiểm tra gì?” vẫn còn bỏ ngỏ. BDD giải quyết vấn đề này bằng cách chuyển trọng tâm từ kiểm tra mã sang mô tả hành vi hệ thống từ góc nhìn của người dùng.

Cải tiến chính của BDD là ngôn ngữ chung cho tất cả những người tham gia dự án. Nhà phát triển, kiểm thử viên, nhà phân tích và khách hàng thảo luận về các kịch bản bằng một ngôn ngữ thống nhất đồng thời đóng vai trò là một bài kiểm tra có thể thực thi. Điều này loại bỏ vấn đề kinh điển “điện thoại hỏng” khi yêu cầu mất ý nghĩa khi truyền từ nhà phân tích đến nhà phát triển.

Lịch sử hình thành BDD

Dan North đã công thức hóa BDD vào năm 2006 trong bài viết “Introducing BDD” trên blog ThinkCode. Ông nhận thấy rằng tên của các bài kiểm tra trong TDD thường được đặt theo thuật ngữ triển khai (“testAddUser”) thay vì thuật ngữ hành vi (“người dùng có thể đăng ký bằng email”). BDD đã thay thế từ “test” bằng “should” và “assert” bằng “expect”, chuyển trọng tâm sang giá trị cho người dùng.

BDD như một thực hành giao tiếp

Theo nghiên cứu của Đại học Cambridge (2021), các dự án sử dụng kịch bản BDD trong giao tiếp với khách hàng giảm 35% lỗi yêu cầu so với đặc tả truyền thống trong tài liệu văn bản. Các kịch bản có thể thực thi không cho phép công thức mơ hồ — mỗi Given-When-Then hoặc là đạt hoặc là không.

Ngôn ngữ Gherkin và cú pháp

Gherkin là một ngôn ngữ dành riêng cho miền được sử dụng bởi các framework Cucumber và SpecFlow để mô tả kịch bản hành vi. Gherkin sử dụng thụt lề và từ khóa để cấu trúc các kịch bản trong khi vẫn dễ đọc cho những người không có nền tảng kỹ thuật.

Feature: Login
  Scenario: Successful login with valid credentials
    Given the user is on the login screen
    When they enter valid username and password
    Then they should see the home screen

Từ khóa Gherkin

Gherkin định nghĩa một số từ khóa cơ bản. Feature mô tả chức năng, Scenario mô tả một kịch bản cụ thể, Given mô tả điều kiện tiên quyết, When mô tả hành động, Then mô tả kết quả mong đợi. Ngoài ra, And và But được sử dụng để kết hợp nhiều điều kiện.

Cấu trúc tệp .feature

Các tệp Gherkin có phần mở rộng .feature và được lưu trữ trong thư mục src/test/resources/features/ trong các dự án Android. Mỗi tệp bắt đầu bằng mô tả Feature, tiếp theo là một hoặc nhiều Scenario. Để tham số hóa, Scenario Outline với bảng Examples được sử dụng — điều này cho phép chạy cùng một kịch bản với dữ liệu khác nhau.

Feature: Calculator
  Scenario Outline: Addition of two numbers
    Given the calculator is running
    When I add <a> and <b>
    Then the result should be <result>

    Examples:
      | a | b | result |
      | 2 | 3 | 5     |
      | 0 | 0 | 0     |
      | -1| 1 | 0     |

Định dạng Given-When-Then

Given-When-Then là một mẫu cấu trúc để mô tả kịch bản, được BDD áp dụng từ thiết kế hướng miền. Mỗi kịch bản bao gồm ba phần: điều kiện tiên quyết, hành động và kết quả mong đợi. Định dạng này tương ứng tự nhiên với Arrange-Act-Assert từ kiểm thử đơn vị nhưng sử dụng ngôn ngữ thân thiện với kinh doanh.

Given: bối cảnh

Khối Given mô tả trạng thái hệ thống trước khi bắt đầu kịch bản: dữ liệu nào tồn tại, thành phần nào đang hoạt động, ứng dụng đang ở chế độ nào. Trong bối cảnh di động, điều này có thể là “người dùng đã đăng nhập”, “giỏ hàng không trống” hoặc “thiết bị đang ở chế độ ngoại tuyến”.

When: hành động

Khối When mô tả một sự kiện được kích hoạt bởi người dùng hoặc hệ thống: nhấn nút, nhận thông báo push, phản hồi máy chủ. Trong ứng dụng di động, điều này thường tương ứng với việc gọi phương thức ViewModel hoặc nhấp vào phần tử giao diện.

Then: kết quả

Khối Then mô tả sự thay đổi trạng thái mong đợi: thay đổi màn hình, gọi API, cập nhật cơ sở dữ liệu. Các kiểm tra trong Then phải có thể đo lường và rõ ràng — chúng trở thành các xác nhận trong mã có thể thực thi.

BDD và TDD: so sánh phương pháp

BDD và TDD thường bị nhầm lẫn, mặc dù chúng là các cấp độ kỷ luật khác nhau. TDD là một kỹ thuật thiết kế ở cấp mã: “cách viết triển khai”. BDD là một kỹ thuật đặc tả ở cấp yêu cầu: “những gì hệ thống nên làm”.

Tính bổ sung trong dự án

Các dự án di động tốt nhất sử dụng TDD ở cấp lớp riêng lẻ (tầng miền) và BDD ở cấp kịch bản (tầng tính năng). Điều này cung cấp bao phủ kép: TDD đảm bảo tính đúng đắn của triển khai, BDD đảm bảo tính đúng đắn của hiểu yêu cầu. Google trong thực hành nội bộ sử dụng kết hợp TDD và BDD cho các ứng dụng Android, như được nêu trong tài liệu Android Testing (2024).

Công cụ BDD cho phát triển di động

Hệ sinh thái BDD bao gồm các framework cho tất cả các nền tảng và ngôn ngữ phát triển di động phổ biến. Việc chọn công cụ phụ thuộc vào công nghệ và mức độ tự động hóa.

Cucumber cho Android

Cucumber là framework BDD phổ biến nhất, làm việc với các kịch bản Gherkin. Cho các dự án Android, thư viện io.cucumber:cucumber-android được sử dụng, tích hợp với các công cụ kiểm thử giao diện Espresso và Compose Test. Cucumber hỗ trợ Kotlin và Java, biến nó thành lựa chọn phổ quát cho các studio sử dụng cả hai ngôn ngữ.

SpecFlow cho Xamarin

SpecFlow là framework BDD cho hệ sinh thái .NET, được sử dụng trong các dự án Xamarin.Forms và .NET MAUI. SpecFlow tích hợp với NUnit và xUnit, và các step definitions của nó được viết bằng C#. Cho các dự án di động, SpecFlow cho phép tái sử dụng kịch bản giữa phiên bản Android và iOS của ứng dụng trên cùng một cơ sở mã.

Quick/Nimble cho iOS

Cho phát triển iOS bằng Swift, có các framework BDD Quick và Nimble. Quick cung cấp DSL để mô tả kịch bản theo phong cách describe/it, và Nimble cung cấp các bộ so khớp với cú pháp dễ đọc. Mặc dù các framework này không sử dụng Gherkin trực tiếp, chúng thực hiện nguyên tắc BDD: mô tả hành vi bằng ngôn ngữ mà toàn bộ nhóm có thể hiểu.

Ví dụ kịch bản BDD và mã

Hãy xem một ví dụ hoàn chỉnh về BDD trong dự án Android: kịch bản thanh toán đơn hàng. Đầu tiên chúng ta viết kịch bản Gherkin, sau đó là step definitions bằng Kotlin.

Nguyên lý hoạt động của BDD: three amigos

Phương pháp BDD dựa trên cuộc họp three amigos — ba vai trò: nhà phát triển, kiểm thử viên và nhà phân tích. Họ cùng nhau viết kịch bản trước khi bắt đầu phát triển, thiết lập sự hiểu biết chung về yêu cầu. Nếu một trong ba người tham gia không hiểu kịch bản, điều đó có nghĩa là yêu cầu được công thức hóa một cách mơ hồ. Thực hành này được mô tả trong cuốn sách “Discovery: Explore Behaviour Using Examples” (Gáspár & North, 2021) và là một phần bắt buộc của quy trình BDD trong các nhóm trưởng thành.

Kịch bản Gherkin thanh toán đơn hàng

Feature: Order Checkout
  Scenario: Apply promo code to cart
    Given the user has items in the cart
    And the total amount is $100
    When they apply promo code "WELCOME10"
    Then the discount should be $10
    And the final total should be $90

Step definitions bằng Kotlin

Step definitions là mã kết nối các kịch bản Gherkin với triển khai kiểm thử. Mỗi bước là một phương thức với chú thích tương ứng với một từ khóa Gherkin.

class CheckoutSteps {
    private val cart = Cart()
    private val checkout = CheckoutUseCase()

    fun `user has items in the cart`() {
        cart.addItem(Item("Phone", 100.0))
    }

    fun `apply promo code`(code: String) {
        checkout.applyPromo(cart, code)
    }

    fun `discount should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getDiscount())
    }

    fun `final total should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getTotal())
    }
}

Tích hợp với Cucumber Android

Để chạy kiểm thử BDD trong dự án Android, CucumberAndroidJUnitRunner được sử dụng. Nó quét các tệp .feature trong tài nguyên, tìm step definitions tương ứng bằng biểu thức chính quy và thực thi các kịch bản như các kiểm thử công cụ thông thường. Kết quả được định dạng thành báo cáo HTML dễ hiểu cho khách hàng.

// build.gradle.kts
dependencies {
    androidTestImplementation("io.cucumber:cucumber-android:7.18.0")
    androidTestImplementation("io.cucumber:cucumber-junit:7.18.0")
}

// CucumberOptions annotation
@RunWith(Cucumber::class)
@CucumberOptions(features = "features", glue = ["com.app.steps"])
class CucumberTestRunner

Thách thức khi áp dụng BDD trong dự án di động

Việc áp dụng BDD trong phát triển di động đi kèm với một số khó khăn thực tế. Hiểu những vấn đề này giúp các nhóm tránh thất vọng và xây dựng quy trình BDD bền vững.

Bảo trì tệp .feature

Vấn đề chính là mất đồng bộ giữa kịch bản Gherkin và mã sản xuất. Nếu nhà phát triển thay đổi API mà không cập nhật step definitions, các tệp .feature không còn khớp với triển khai. Giải pháp là chạy kiểm thử BDD trong pipeline CI/CD và yêu cầu trạng thái xanh cho các yêu cầu hợp nhất. Thực hành “BDD as a gating mechanism” được mô tả trong tài liệu Cucumber (2024) và là tiêu chuẩn trong ngành.

Hiệu suất kiểm thử BDD

Các kịch bản BDD trong Cucumber chạy như kiểm thử công cụ trên thiết bị Android hoặc trình giả lập. Điều này chậm hơn 10–50 lần so với kiểm thử đơn vị thông thường trên JVM. Một kiểm thử chấp nhận duy nhất có thể mất 20–30 phút cho một ứng dụng Android lớn. Khuyến nghị chạy kiểm thử BDD trong một công việc CI riêng vào ban đêm, trong khi kiểm thử đơn vị chạy trên mỗi lần đẩy. Chiến lược này cân bằng tốc độ phản hồi và bao phủ kịch bản.

Đào tạo nhóm về Gherkin

Chuyển đổi sang BDD yêu cầu đào tạo không chỉ nhà phát triển mà còn nhà phân tích và kiểm thử viên. Gherkin là một ngôn ngữ đơn giản, nhưng viết kịch bản tốt đòi hỏi thực hành. Lỗi điển hình của người mới bắt đầu: kịch bản quá dài (hơn 10 bước), trộn lẫn Given-When-Then, sử dụng thuật ngữ kỹ thuật trong kịch bản kinh doanh. Theo BDD Academy (2024), các nhóm cần trung bình 4–6 sprint để đạt được sự thành thạo trong việc viết kịch bản BDD.