Phát triển theo hướng hành vi (Behavior-Driven Development) đã thay đổi cơ bản cách các nhóm suy nghĩ về chất lượng phần mềm bằng cách làm cho các bài kiểm thử trở nên dễ đọc đối với tất cả mọi người! Sử dụng Cucumber cho kiểm thử BDD là một kỹ năng thu hẹp khoảng cách giữa yêu cầu nghiệp vụ và triển khai kỹ thuật, tạo ra tài liệu sống động thực sự được thực thi. Nếu bạn đã từng gặp khó khăn với các trường hợp kiểm thử lỗi thời ngay khi chúng được viết, hướng dẫn này sẽ chỉ cho bạn một cách tốt hơn.
Cucumber và BDD là gì?
Cucumber là một công cụ mã nguồn mở chạy các bài kiểm thử tự động được viết bằng ngôn ngữ tự nhiên. Nó triển khai Phát triển theo hướng hành vi (BDD), một phương pháp luận mà các nhà phát triển, người kiểm thử và các bên liên quan trong kinh doanh cùng hợp tác để xác định hành vi của phần mềm bằng cách sử dụng các ví dụ cụ thể.
BDD tập trung vào việc trả lời một câu hỏi: "Hệ thống nên làm gì?" thay vì "Chúng ta nên kiểm thử nó như thế nào?" Kết quả là một ngôn ngữ chung giúp loại bỏ những hiểu lầm và tạo ra các bài kiểm thử vừa là thông số kỹ thuật vừa là xác thực có thể thực thi được.
Cucumber đọc các tệp .feature chứa các kịch bản được viết bằng cú pháp Gherkin và thực thi chúng dựa trên các định nghĩa bước (step definitions)—mã thực hiện tự động hóa thực tế. Sự tách biệt này có nghĩa là các bên liên quan trong kinh doanh có thể xem xét các kịch bản kiểm thử mà không cần đọc mã, trong khi các nhà phát triển triển khai các chi tiết kỹ thuật một cách riêng biệt.
Cài đặt Cucumber cho JavaScript
Thiết lập Cucumber trong một dự án Node.js chỉ mất vài lệnh:
Điều kiện tiên quyết:
- Node js
- NPM
- Một dự án API có tính năng đăng nhập mà chúng ta sẽ kiểm thử (Hướng dẫn này sẽ chỉ bao gồm cài đặt Cucumber và các bài kiểm thử Gherkin).
# Create a new project directory
mkdir cucumber-bdd-demo && cd cucumber-bdd-demo
# Initialize npm
npm init -y
# Install Cucumber and testing dependencies
npm install --save-dev @cucumber/cucumber chai axios
Tệp package.json của bạn nên bao gồm một script kiểm thử:
{
"scripts": {
"test": "cucumber-js"
}
}
Tạo cấu trúc thư mục sau:
project/
├── features/
│ └── user-management.feature
├── step-definitions/
│ └── user-steps.js
├── package.json
└── cucumber.json
Hướng dẫn thực hành: Viết bài kiểm thử BDD đầu tiên của bạn
Hãy cùng xây dựng một bài kiểm thử cho API quản lý người dùng để minh họa Cách sử dụng Cucumber cho kiểm thử BDD trong thực tế.
Bước 1: Viết tệp Feature
Tạo tệp features/user-management.feature:
Feature: API Quản lý Người dùng
Là một client API
Tôi muốn quản lý người dùng
Để tôi có thể tích hợp chức năng người dùng vào ứng dụng của mình
Scenario: Tạo người dùng mới thành công
Given Tôi có một payload người dùng hợp lệ
When Tôi gửi một yêu cầu POST đến "/api/users"
Then trạng thái phản hồi phải là 201
And phản hồi phải chứa một ID người dùng
Scenario: Thử tạo người dùng với email không hợp lệ
Given Tôi có một payload người dùng với email không hợp lệ
When Tôi gửi một yêu cầu POST đến "/api/users"
Then trạng thái phản hồi phải là 400
And phản hồi phải chứa "Invalid email format"
Bước 2: Triển khai Định nghĩa Bước
Tạo tệp step-definitions/user-steps.js:
const { Given, When, Then } = require('@cucumber/cucumber');
const { expect } = require('chai');
const axios = require('axios');
let requestPayload;
let response;
Given('I have a valid user payload', function() {
requestPayload = {
name: 'Test User',
email: 'test@example.com',
password: 'ValidPass123'
};
});
Given('I have a user payload with invalid email', function() {
requestPayload = {
name: 'Test User',
email: 'invalid-email',
password: 'ValidPass123'
};
});
When('I send a POST request to {string}', async function(endpoint) {
try {
response = await axios.post(`http://localhost:3000${endpoint}`, requestPayload);
} catch (error) {
response = error.response;
}
});
Then('the response status should be {int}', function(statusCode) {
expect(response.status).to.equal(statusCode);
});
Then('the response should contain a user ID', function() {
expect(response.data).to.have.property('userId');
expect(response.data.userId).to.match(/^[0-9a-fA-F]{24}$/);
});
Then('the response should contain {string}', function(message) {
expect(response.data.message).to.include(message);
});
Bước 3: Chỉnh sửa tệp Cucumber.json
Tạo một tệp "cucumber.json" trong thư mục gốc của dự án và thêm đoạn mã sau:
{
"default": {
"formatOptions": {
"snippetInterface": "synchronous"
}
}
}Bước 4: Chạy các bài kiểm thử
Thực thi các bài kiểm thử của bạn bằng cách:
npm test
Cucumber sẽ xuất ra kết quả chi tiết, hiển thị các bước nào đã vượt qua, chưa được định nghĩa hoặc thất bại.
Quy tắc để viết các kịch bản BDD tốt
Học Cách sử dụng Cucumber cho kiểm thử BDD một cách hiệu quả yêu cầu tuân thủ các quy tắc đã được chứng minh sau đây:
1. Cấu trúc Given-When-Then
Mọi kịch bản phải có ba phần này theo thứ tự:
- Given: Thiết lập các điều kiện tiên quyết
- When: Mô tả hành động
- Then: Xác thực kết quả
2. Viết theo kiểu khai báo, không phải mệnh lệnh
Không tốt:
Given Tôi mở trình duyệt
And Tôi điều hướng đến "/login"
And Tôi nhập "test@example.com" vào trường email
And Tôi nhập "password" vào trường mật khẩu
And Tôi nhấp vào nút đăng nhập
Tốt:
Given Tôi đang ở trang đăng nhập
When Tôi đăng nhập với thông tin đăng nhập hợp lệ
Then Tôi sẽ thấy trang tổng quan
Tập trung vào điều bạn đang kiểm thử, không phải cách bạn thực hiện nó.
3. Một Kịch bản, Một Mục đích
Mỗi kịch bản chỉ nên kiểm thử một hành vi duy nhất. Các kịch bản kết hợp sẽ che giấu lỗi và gây khó khăn cho việc gỡ lỗi.
4. Sử dụng Ngôn ngữ Nghiệp vụ
Viết các kịch bản mà các bên liên quan trong kinh doanh có thể hiểu được. Tránh các thuật ngữ kỹ thuật và chi tiết triển khai.
5. Làm cho các Kịch bản độc lập
Các kịch bản không nên phụ thuộc vào nhau. Mỗi kịch bản nên tự thiết lập dữ liệu riêng và dọn dẹp sau đó.
Các tính năng Cucumber nâng cao: Bảng dữ liệu và Dàn ý kịch bản
Bảng dữ liệu cho đầu vào phức tạp
Khi bạn cần kiểm thử với nhiều điểm dữ liệu, hãy sử dụng bảng:
Scenario: Tạo người dùng với các vai trò khác nhau
Given Tôi có dữ liệu người dùng sau:
| name | email | role |
| Alice | alice@example.com | admin |
| Bob | bob@example.com | user |
When Tôi gửi một yêu cầu POST đến "/api/users"
Then tất cả người dùng phải được tạo thành công
Định nghĩa bước:
Given('I have the following user data:', function(dataTable) {
requestPayload = dataTable.hashes();
});
Dàn ý kịch bản cho kiểm thử dựa trên dữ liệu
Khi bạn muốn chạy cùng một kịch bản với dữ liệu khác nhau, hãy sử dụng dàn ý:
Scenario Outline: Đăng nhập với các thông tin xác thực khác nhau
Given Tôi đang ở trang đăng nhập
When Tôi nhập "" và ""
Then Tôi sẽ thấy ""
Examples:
| email | password | result |
| test@example.com | validPass | Bảng điều khiển |
| test@example.com | wrongPass | Mật khẩu không hợp lệ|
| invalid@email.com | validPass | Email không hợp lệ |
Điều này tự động tạo ra ba kịch bản kiểm thử riêng biệt.
Tổ chức các bài kiểm thử bằng Thẻ
Thẻ giúp bạn phân loại và lọc các kịch bản:
@smoke @regression
Scenario: Đăng nhập người dùng
Given Tôi đang ở trang đăng nhập
When Tôi đăng nhập với thông tin đăng nhập hợp lệ
Then Tôi sẽ thấy trang tổng quan
@api @critical
Scenario: Kiểm tra tình trạng API
Given API đang chạy
When Tôi yêu cầu "/health"
Then trạng thái phản hồi phải là 200
Chỉ chạy các thẻ cụ thể:
npm test -- --tags "@smoke"
Apidog hỗ trợ Kiểm thử API trong quy trình làm việc BDD như thế nào
Trong khi Cucumber nổi bật trong việc định nghĩa hành vi, Apidog tự động hóa các công việc nặng nhọc trong việc tạo và thực thi kiểm thử API, giúp kiểm thử Cucumber cho BDD hiệu quả hơn nhiều.
Tạo trường hợp kiểm thử API được hỗ trợ bởi AI
Thay vì viết thủ công các định nghĩa bước cho các lệnh gọi API, Apidog tạo chúng từ thông số kỹ thuật OpenAPI của bạn bằng AI:
# Your API spec
paths:
/api/users:
post:
requestBody:
content:
application/json:
schema:
type: object
properties:
name: string
email: string
responses:
'201':
description: User created
Apidog tự động tạo các kịch bản sẵn sàng để kiểm thử:
- Kiểm thử tích cực: Payload hợp lệ → trạng thái 201
- Kiểm thử tiêu cực: Email không hợp lệ → trạng thái 400
- Kiểm thử biên: Thiếu trường bắt buộc → trạng thái 400
Các câu hỏi thường gặp
H1: Tôi có cần biết lập trình để viết các bài kiểm thử Cucumber không?
Trả lời: Viết kịch bản Gherkin không yêu cầu viết mã—chỉ cần suy nghĩ rõ ràng về hành vi. Tuy nhiên, việc triển khai định nghĩa bước yêu cầu kiến thức JavaScript (hoặc ngôn ngữ khác). Các công cụ như Apidog giảm bớt gánh nặng này bằng cách tự động tạo mã định nghĩa bước.
H2: Cucumber khác với các framework kiểm thử truyền thống như thế nào?
Trả lời: Các framework truyền thống (Jest, Mocha) tập trung vào triển khai kỹ thuật. Cucumber tập trung vào hành vi nghiệp vụ. Cùng một kịch bản Cucumber có thể điều khiển kiểm thử giao diện người dùng web (Selenium), kiểm thử API (Axios) hoặc kiểm thử di động (Appium) mà không cần thay đổi văn bản Gherkin.
H3: Cucumber có thể thay thế các công cụ kiểm thử API không?
Trả lời: Cucumber cung cấp cấu trúc kiểm thử, nhưng bạn vẫn cần các công cụ để thực thi các lệnh gọi API (Axios, Supertest) và xác thực phản hồi. Apidog bổ trợ Cucumber bằng cách xử lý lớp thực thi API trong khi Cucumber quản lý quy trình làm việc BDD.
H4: Điều gì tạo nên một kịch bản Cucumber tốt?
Trả lời: Các kịch bản tốt phải độc lập, sử dụng ngôn ngữ nghiệp vụ, tuân thủ cấu trúc Given-When-Then và kiểm thử một hành vi duy nhất. Chúng phải dễ đọc đối với các bên liên quan không chuyên về kỹ thuật và tập trung vào những gì hệ thống làm, không phải cách nó làm.
H5: Apidog xử lý xác thực trong các bài kiểm thử BDD như thế nào?
Trả lời: Apidog tự động quản lý các token xác thực. Bạn có thể định nghĩa các bước "Given I am authenticated" sử dụng quản lý thông tin xác thực của Apidog để truy xuất các token hợp lệ, loại bỏ việc xử lý token thủ công trong định nghĩa bước của bạn.
Kết luận
Sử dụng Cucumber để kiểm thử BDD sẽ thay đổi hiệu quả quy trình phát triển của bạn bằng cách tạo ra sự hiểu biết chung giữa các nhóm kỹ thuật và nghiệp vụ. Cú pháp Gherkin buộc phải rõ ràng, trong khi việc tách biệt các kịch bản và định nghĩa bước giúp các bài kiểm thử dễ bảo trì khi ứng dụng của bạn phát triển.
Sức mạnh thực sự đến từ việc tích hợp Cucumber với các công cụ tự động hóa hiện đại. Apidog loại bỏ công việc thủ công tẻ nhạt khi viết mã kiểm thử API, cho phép bạn tập trung vào việc định nghĩa các hành vi có ý nghĩa trong khi nó xử lý việc thực thi. Sự kết hợp này mang lại điều tốt nhất từ cả hai thế giới: các thông số kỹ thuật dễ đọc đối với con người, đóng vai trò là tài liệu sống, và các bài kiểm thử tự động mạnh mẽ chạy liên tục.
Bắt đầu từ nhỏ. Chọn một điểm cuối API. Viết ba kịch bản: thành công, thất bại và trường hợp biên. Triển khai các định nghĩa bước. Chạy chúng. Cho chủ sản phẩm của bạn xem kết quả. Khi họ thấy các yêu cầu nghiệp vụ được thực thi dưới dạng kiểm thử, bạn sẽ nhận được sự đồng thuận để mở rộng BDD trên toàn bộ dự án của mình. Đó là lúc việc sử dụng Cucumber cho kiểm thử BDD không còn là một thực hành kỹ thuật mà trở thành một phong trào chất lượng toàn đội.