📖 BDD là gì?
Mô tả hành vi bằng lời thường để ai cũng đọc được.
1
Hiểu nó là gì
BDD viết yêu cầu thành các tình huống bằng ngôn ngữ gần đời thường, để dev, tester và người làm nghiệp vụ hiểu giống nhau về cùng một tính năng.
Nói theo đời thường:
Thay vì đưa bản vẽ kỹ thuật cho khách xem, mình kể: khách bấm đặt hàng thì phải nhận được tin nhắn xác nhận. Ai nghe cũng gật được.
Thay vì đưa bản vẽ kỹ thuật cho khách xem, mình kể: khách bấm đặt hàng thì phải nhận được tin nhắn xác nhận. Ai nghe cũng gật được.
⚠ Chỗ ẩn dụ này hỏng
Ai nghe cũng gật — nhưng gật không có nghĩa là hiểu giống nhau.
BDD chỉ có giá trị nếu người làm nghiệp vụ thật sự ngồi vào viết cùng. Nếu chỉ có tester tự viết Given/When/Then rồi tự đọc, bạn đã tốn thêm một lớp cú pháp mà chẳng ai ngoài bạn đọc. Đây là lý do phần lớn dự án BDD thất bại: giữ lại phần hình thức, bỏ mất phần trò chuyện.
2
Code trông thế nào
Tính năng: Đăng nhập
Kịch bản: Sai mật khẩu
Cho trước tài khoản na@vd.com đã tồn tại
Khi tôi đăng nhập bằng mật khẩu sai
Thì tôi thấy thông báo "Sai email hoặc mật khẩu"
Người làm nghiệp vụ đọc được, sửa được — đó mới là mục đích.
3
Khi nào bạn dùng nó
✓ Dùng khi
- Nghiệp vụ phức tạp, dev và BA hay hiểu lệch nhau
- Có người làm nghiệp vụ chịu ngồi viết cùng
✗ Đừng dùng khi
- Chỉ tester tự viết tự đọc
- Nghiệp vụ đơn giản, viết ca test thường là đủ
Chưa cần biết: nối bước với code (step definition), tham số hoá kịch bản, sinh tài liệu sống.
Để dành tới Mốc 2 — Tự viết được cái đầu tiên: Bạn viết được một test mở trang, bấm nút, kiểm tra chữ hiện ra — và nó chạy xanh trên máy bạn.
Dấu hiệu bạn đã cần học nó: Khi cả đội đã đồng ý dùng Gherkin và bạn cần biến các dòng đó thành test chạy được.
4
Đi đâu tiếp
- GherkinCú pháp cụ thể để viết kịch bản BDD.
- Test CaseCùng mục đích, khác cách trình bày.
- TDDAnh em cùng tinh thần, ở tầng kỹ thuật hơn.