𝟯 Điều Không Ai Nói Với Bạn Về BDD

Bộ suite Cucumber của bạn mất tới 40 phút để chạy. Bạn không thể giải thích được một file feature duy nhất đang kiểm thử cái gì nếu không phải đọc qua hàng lớp mã nguồn.

Nhiều đội ngũ áp dụng BDD vì các bên liên quan (stakeholders) về mặt kinh doanh cần đọc các bản kiểm thử. Sau đó, những người này lại ngừng đọc. Kết quả là bạn rơi vào một cơn ác mộng về bảo trì.

Dưới đây là ba sự thật về BDD.

𝟭. 𝗚𝗵𝗲𝗿𝗸𝗶𝗻 𝗶𝘀 𝗻𝗼𝘁 𝗮 𝗽𝗿𝗼𝗴𝗿𝗮𝗺𝗺𝗶𝗻𝗴 𝗹𝗮𝗻𝗴𝘂𝗮𝗴𝗲

Hãy ngừng viết kịch bản kiểm thử (test scripts) bằng Gherkin. Nếu các kịch bản (scenarios) của bạn liệt kê mọi cú click và mọi trường dữ liệu, bạn đang làm sai cách.

Gherkin tồi:

  • Given the user enters email "test@example.com"
  • And the user enters password "Password123!"
  • And the user clicks "Place Order"

Gherkin tốt:

  • Given the user has items ready to purchase
  • When the user pays with a valid credit card
  • Then the order is confirmed

Phần "làm thế nào" (how) nằm trong các step definitions. Phần "cái gì" (what) nằm trong các feature files. Hãy giữ cho các feature files thật đơn giản để một quản lý sản phẩm (product manager) có thể đọc hiểu chúng chỉ trong vài giây.

𝟮. 𝗦𝘁𝗲𝗽 𝗱𝗲𝗳𝗶𝗻𝗶𝘁𝗶𝗼𝗻𝘀 𝗮𝗿𝗲 𝗻𝗼𝘁 𝗮 𝗱𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 𝗴𝗿𝗮𝗽𝗵

Đừng để các step definitions import các step definitions khác. Điều này tạo ra một mạng lưới chằng chịt. Nếu một bước thất bại, nó sẽ làm hỏng toàn bộ trạng thái (state).

Cách khắc phục rất đơn giản:

  • Tách biệt các page objects khỏi các step definitions.
  • Sử dụng một lớp domain dùng chung (shared domain layer).
  • Các step definitions nên là những lớp bao bọc mỏng (thin wrappers) dùng để gọi các domain objects.

Điều này giúp các bước của bạn không phụ thuộc vào trạng thái (stateless). Bạn có thể thay đổi một phần mã nguồn mà không làm hỏng mọi kịch bản khác.

𝟯. 𝗕𝗗𝗗 𝗶𝘀 𝗮 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 𝗽𝗿𝗼𝗷𝗲𝗰𝘁

BDD là về sự giao tiếp, không chỉ là kiểm thử. Các bản kiểm thử chỉ là một tác dụng phụ.

Nếu bạn chỉ tối ưu hóa cho độ bao phủ kiểm thử (test coverage) hoặc tốc độ thực thi, bạn sẽ mất đi mục tiêu chính. Các feature files nên là thứ đầu tiên mà một kỹ sư mới đọc để hiểu hệ thống của bạn.

Nếu một người không thể hiểu hệ thống của bạn thông qua việc đọc các feature files, thì bộ suite BDD của bạn đã thất bại.

𝗪𝗵𝗮𝘁 𝘁𝗼 𝗱𝗼 𝘁𝗼𝗺𝗼𝗿𝗿𝗼𝘄:

  • Chọn ra file feature tệ nhất của bạn.
  • Viết lại các kịch bản sao cho chỉ dài từ ba đến năm dòng.
  • Chuyển dữ liệu vào các step definitions hoặc factories.
  • Thay thế việc import giữa các bước bằng các domain objects.

Bạn có thể giải thích hệ thống của mình cho một nhân viên mới chỉ bằng cách sử dụng các feature files trong vòng năm phút không? Nếu không, hãy bắt đầu viết lại ngay.

3 điều không ai nói với bạn về BDD trước khi bộ Cucumber của bạn trở thành một cơn ác mộng bảo trì

BDD (Behavior-Driven Development) thường được ca ngợi là "chén thánh" để thu hẹp khoảng cách giữa các bên liên quan về kinh doanh và đội ngũ kỹ thuật. Tuy nhiên, nếu không được thực hiện đúng cách, nó có thể nhanh chóng biến thành một cơn ác mộng về bảo trì.

Dưới đây là 3 điều mà ít người nói với bạn khi bắt đầu với BDD:

1. Cái bẫy Gherkin theo kiểu mệnh lệnh (The Imperative Gherkin Trap)

Sai lầm phổ biến nhất là viết các kịch bản Gherkin mô tả quá chi tiết từng bước thao tác nhỏ nhặt. Thay vì viết:

Given I am on the login page
And I enter "user@example.com" in the email field
And I enter "password123" in the password field
And I click the "Login" button

Bạn nên viết theo phong cách khai báo (declarative):

Given I am a logged-in user

Khi bạn viết theo kiểu mệnh lệnh (imperative), bất kỳ thay đổi nhỏ nào về giao diện người dùng (UI) cũng sẽ khiến hàng loạt kịch bản của bạn bị lỗi, dẫn đến việc phải cập nhật liên tục.

2. Sự bùng nổ của Step Definition (Step Definition Explosion)

Khi các kịch bản Gherkin quá chi tiết, bạn sẽ rơi vào tình trạng tạo ra quá nhiều Step Definition gần như giống hệt nhau. Điều này khiến bộ mã nguồn của bạn trở nên cồng kềnh và cực kỳ khó quản lý.

Thay vì tạo ra một bước mới cho mỗi hành động nhỏ, hãy sử dụng tham số hóa (parameterization) và regex để làm cho các bước có thể tái sử dụng được. Mục tiêu là có ít Step Definition nhất có thể nhưng vẫn bao phủ được tất cả các kịch bản.

3. Sự nhầm lẫn giữa "Cái gì" và "Như thế nào" (The "What" vs "How" Confusion)

Gherkin được thiết kế để mô tả hành vi (cái gì đang xảy ra), không phải cách thức triển khai (nó được thực hiện như thế nào).

Nếu kịch bản của bạn chứa quá nhiều chi tiết kỹ thuật (như "nhấp vào nút", "chờ 2 giây", "kiểm tra phần tử DOM"), bạn đã đánh mất lợi ích lớn nhất của BDD: khả năng đọc hiểu của các bên liên quan (stakeholders) không thuộc bộ phận kỹ thuật. Kịch bản phải là một tài liệu sống mà bất kỳ ai trong doanh nghiệp cũng có thể hiểu được.

Tóm lại: Để tránh biến bộ Cucumber của bạn thành một cơn ác mộng, hãy tập trung vào việc viết các kịch bản mang tính khai báo, ưu tiên khả năng tái sử dụng và luôn giữ cho ngôn ngữ Gherkin ở mức độ kinh doanh thay vì kỹ thuật.