BDD - TDD theo cách BDD
Trong TDD, thuật ngữ “Kiểm tra chấp nhận” bị hiểu nhầm. Kiểm thử chấp nhận thực sự đại diện cho hành vi mong đợi của hệ thống. Trong thực hành Agile, sự hợp tác của cả nhóm và tương tác với khách hàng và các bên liên quan khác được nhấn mạnh. Điều này đã làm phát sinh sự cần thiết của việc sử dụng các thuật ngữ mà mọi người tham gia vào dự án dễ hiểu.
TDD khiến bạn suy nghĩ về những điều bắt buộc Behavior và do đó thuật ngữ 'Hành vi' hữu ích hơn thuật ngữ ‘Test’. BDD là Phát triển theo hướng kiểm tra với từ vựng tập trung vào hành vi chứ không phải kiểm tra.
Theo lời của Dan North, “Tôi nhận thấy sự thay đổi từ suy nghĩ trong các bài kiểm tra sang suy nghĩ trong hành vi sâu sắc đến mức tôi bắt đầu gọi TDD là BDD, hoặc Phát triển theo hướng hành vi.” TDD tập trung vào cách một thứ gì đó sẽ hoạt động, BDD tập trung vào lý do tại sao chúng tôi xây dựng nó.
BDD trả lời các câu hỏi sau mà các nhà phát triển thường gặp phải -
Câu hỏi | Câu trả lời |
---|---|
Bắt đầu từ đâu? | ngoài vào trong |
Kiểm tra những gì? | Câu chuyện của người dùng |
Những gì không để kiểm tra? | còn gì nữa không |
Những câu trả lời này dẫn đến khung câu chuyện như sau:
Story Framework
Như một [Role]
tôi muốn [Feature]
vậy nên [Benefit]
Điều này có nghĩa là, 'Khi một Feature được thực thi, kết quả Benefit là cho Người chơi Role.'
BDD trả lời thêm các câu hỏi sau:
Câu hỏi | Câu trả lời |
---|---|
Bao nhiêu để kiểm tra trong một lần? | rất ít tập trung |
Những gì để gọi các bài kiểm tra của họ? | mẫu câu |
Làm thế nào để hiểu tại sao một bài kiểm tra không thành công | tài liệu |
Những câu trả lời này dẫn đến khung Ví dụ như sau:
Example Framework
Given một số bối cảnh ban đầu,
When một sự kiện xảy ra,
Then đảm bảo một số kết quả.
Điều này có nghĩa là, 'Bắt đầu với bối cảnh ban đầu, khi một sự kiện cụ thể xảy ra, chúng ta biết kết quả should be. '
Vì vậy, ví dụ cho thấy hành vi mong đợi của hệ thống. Các ví dụ được sử dụng để minh họa các tình huống khác nhau của hệ thống.
Câu chuyện và kịch bản
Chúng ta hãy xem xét minh họa sau đây của Dan North về hệ thống ATM.
Câu chuyện
As a khách hàng,
I want rút tiền mặt từ máy ATM,
so that Tôi không phải xếp hàng chờ đợi tại ngân hàng.
Các tình huống
Có hai tình huống có thể xảy ra cho câu chuyện này.
Scenario 1 - Tài khoản được ghi có
Given tài khoản có tín dụng
And thẻ hợp lệ
And máy rút chứa tiền mặt
When khách hàng yêu cầu tiền mặt
Then đảm bảo tài khoản được ghi nợ
And đảm bảo tiền mặt được phân phối
And đảm bảo thẻ được trả lại
Scenario 2 - Tài khoản được thấu chi vượt quá hạn mức thấu chi
Given tài khoản được thấu chi
And thẻ hợp lệ
When khách hàng yêu cầu tiền mặt
Then đảm bảo thông báo từ chối được hiển thị
And đảm bảo tiền mặt không được phân phối
And đảm bảo thẻ được trả lại
Sự kiện giống nhau trong cả hai tình huống, nhưng bối cảnh khác nhau. Do đó, các kết quả khác nhau.
Chu kỳ phát triển
Chu kỳ phát triển cho BDD là một outside-in tiếp cận.
Step 1- Viết một ví dụ về giá trị kinh doanh cấp cao (bên ngoài) (sử dụng Cucumber hoặc RSpec / Capybara) có màu đỏ. (RSpec tạo khung BDD bằng ngôn ngữ Ruby)
Step 2 - Viết ví dụ RSpec cấp thấp hơn (bên trong) cho bước triển khai đầu tiên có màu đỏ.
Step 3 - Triển khai mã tối thiểu để vượt qua ví dụ cấp thấp hơn đó, thấy nó chuyển sang màu xanh lục.
Step 4 - Viết ví dụ RSpec cấp thấp hơn tiếp theo để chuyển sang Bước 1 có màu đỏ.
Step 5 - Lặp lại các bước Bước 3 và Bước 4 cho đến khi ví dụ cấp cao ở Bước 1 chuyển sang màu xanh lục.
Note - Cần ghi nhớ những điểm sau:
Red/green trạng thái là một trạng thái quyền.
Khi các bài kiểm tra cấp thấp của bạn có màu xanh lục, bạn có quyền viết các ví dụ mới hoặc cấu trúc lại việc triển khai hiện có. Bạn không được, trong bối cảnh tái cấu trúc, thêm chức năng / tính linh hoạt mới.
Khi các thử nghiệm cấp thấp của bạn có màu đỏ, bạn chỉ có quyền viết hoặc thay đổi mã triển khai để làm cho các thử nghiệm hiện có chuyển sang màu xanh lục. Bạn phải chống lại sự thôi thúc viết mã để vượt qua bài kiểm tra tiếp theo không tồn tại hoặc triển khai các tính năng mà bạn có thể cho là tốt (khách hàng sẽ không yêu cầu).