Behavior-Driven Development (BDD) là gì?

Question

Accepted Answer

**Behavior-Driven Development (BDD)** là một cách tiếp cận mô tả hành vi phần mềm bằng **ngôn ngữ tự nhiên, có cấu trúc** (Given-When-Then) mà cả người kỹ thuật và phi kỹ thuật đều hiểu được — bắc cầu giao tiếp giữa lập trình viên, tester và các bên liên quan nghiệp vụ, với test được dẫn xuất từ các mô tả này.

## BDD là gì

```text
BDD tập trung mô tả HÀNH VI bằng ngôn ngữ dễ đọc với nghiệp vụ:
  → viết SCENARIO theo định dạng ngôn ngữ tự nhiên có cấu trúc (Gherkin):
    GIVEN một ngữ cảnh ban đầu nào đó
    WHEN một hành động/sự kiện xảy ra
    THEN một kết quả mong đợi xảy ra
  → các scenario này vừa là TÀI LIỆU vừa là TEST chạy được
→ Bắc cầu dev, QA và các bên liên quan NGHIỆP VỤ với một ngôn ngữ chung, dễ đọc.
```

## Một scenario Gherkin

```gherkin
Feature: User login
  Scenario: Successful login
    Given a registered user with valid credentials
    When they submit the login form
    Then they should see their dashboard
    And a welcome message should be displayed
```

```text
→ Công cụ (Cucumber, SpecFlow, Behave) ánh xạ các bước ngôn ngữ tự nhiên này thành code test chạy được
→ Các bên phi kỹ thuật có thể ĐỌC và thậm chí giúp VIẾT scenario (hiểu biết chung)
```

## BDD vs TDD

```text
TDD → tập trung vào dev; test dẫn dắt thiết kế code; "code có đúng không?" (cấp unit)
BDD → tập trung hành vi/nghiệp vụ; scenario mô tả TÍNH NĂNG bằng ngôn ngữ chung;
  "nó có làm điều nghiệp vụ muốn không?" (cộng tác, yêu cầu dưới dạng test)
→ BDD mở rộng ý tưởng của TDD hướng tới CỘNG TÁC và đặc tả dễ đọc với nghiệp vụ.
  (Given-When-Then = Arrange-Act-Assert theo thuật ngữ nghiệp vụ.)
```

## Tại sao điều này quan trọng

Hiểu Behavior-Driven Development có giá trị vì nó là một cách tiếp cận có ảnh hưởng **nhấn mạnh cộng tác và đặc tả dễ đọc với nghiệp vụ**, nên đây là kiến thức hữu ích để hiểu các thực hành về testing và yêu cầu.

Ý tưởng cốt lõi của BDD — mô tả **hành vi phần mềm bằng ngôn ngữ tự nhiên, có cấu trúc (Given-When-Then)** mà cả người kỹ thuật và phi kỹ thuật đều hiểu được — giải quyết một thách thức thực: giao tiếp giữa lập trình viên, tester và các bên liên quan nghiệp vụ về việc phần mềm nên làm gì.

Bằng cách viết **scenario bằng ngôn ngữ dễ đọc với nghiệp vụ** vừa đóng vai trò **tài liệu vừa là test chạy được** (qua công cụ như Cucumber), BDD tạo ra một hiểu biết chung nơi các bên liên quan có thể đọc và thậm chí giúp viết đặc tả, giảm hiểu lầm về yêu cầu.

Hiểu **cấu trúc Given-When-Then** (Given một ngữ cảnh, When một hành động, Then một kết quả — cách diễn đạt BDD của Arrange-Act-Assert) và cách công cụ ánh xạ các bước ngôn ngữ tự nhiên này thành code test chạy được là kiến thức thực hành.

Hiểu **BDD vs TDD** làm rõ mối quan hệ của chúng: TDD tập trung vào dev (test dẫn dắt thiết kế code, "code có đúng không?"), trong khi BDD tập trung hành vi/nghiệp vụ (scenario mô tả tính năng bằng ngôn ngữ chung, "nó có làm điều nghiệp vụ muốn không?") — với BDD mở rộng ý tưởng của TDD hướng tới cộng tác và đặc tả dễ đọc với nghiệp vụ.

Hiểu BDD phản ánh nhận thức về các thực hành kết nối testing với yêu cầu và giao tiếp với các bên liên quan.

Dù không phải team nào cũng dùng BDD chính thức, các khái niệm (scenario tập trung hành vi, cộng tác, đặc tả chạy được) có ảnh hưởng và đáng hiểu.

Vì BDD là một cách tiếp cận có ảnh hưởng nhấn mạnh cộng tác và đặc tả hành vi dễ đọc với nghiệp vụ (bắc cầu giao tiếp kỹ thuật và nghiệp vụ, với scenario chạy được), và vì hiểu nó và mối quan hệ với TDD phản ánh sự trưởng thành về testing và yêu cầu, hiểu Behavior-Driven Development là kiến thức có giá trị, liên quan — một cách tiếp cận đáng chú ý kết nối testing với cộng tác và yêu cầu, hữu ích để hiểu cách các team có thể căn chỉnh test kỹ thuật với đặc tả dễ đọc với nghiệp vụ và giao tiếp với các bên liên quan.