Behaviour Driven Development (BDD), hay Phát triển phần mềm hướng hành vi, là một quy trình phát triển phần mềm xuất phát từ Test Driven Development (TDD) – Phát triển phần mềm hướng kiểm thử. BDD sử dụng các ví dụ cụ thể để mô tả hành vi của hệ thống bằng ngôn ngữ dễ hiểu cho tất cả các bên liên quan trong dự án. Những ví dụ này đóng vai trò quan trọng trong:
- Chuyển đổi thành các đặc tả kỹ thuật có thể thực thi.
- Sử dụng làm các bài kiểm thử chấp nhận (acceptance test).
BDD tập trung vào việc:
- Tăng cường giao tiếp: Cung cấp một quy trình và công cụ chung để các lập trình viên, chuyên viên phân tích nghiệp vụ (BA) và các bên liên quan khác cộng tác phát triển phần mềm, từ đó tạo ra sản phẩm có giá trị kinh doanh cao.
- Xác định rõ hành vi: Làm rõ hệ thống nên và không nên làm gì, tập trung vào cách thức hoạt động thay vì chi tiết kỹ thuật.
- Nâng cao khả năng đọc hiểu: Cải thiện khả năng đọc và tính minh bạch của mã nguồn.
- Đảm bảo sự hài lòng của khách hàng: Xác minh rằng phần mềm không chỉ hoạt động đúng mà còn đáp ứng được mong đợi của khách hàng.
Chi phí sửa lỗi sẽ tăng đáng kể nếu chúng không được phát hiện và sửa chữa kịp thời.
Minh họa chi phí sửa lỗi tăng theo thời gian trong quy trình phát triển phần mềm
Hình ảnh trên cho thấy tầm quan trọng của việc thu thập yêu cầu chính xác. Việc hiểu sai yêu cầu ở giai đoạn đầu có thể dẫn đến chi phí sửa chữa rất lớn ở các giai đoạn sau và sản phẩm cuối cùng có thể không đáp ứng được kỳ vọng của khách hàng.
Do đó, phương pháp phát triển phần mềm cần phải:
- Dựa trên các yêu cầu.
- Tập trung vào các yêu cầu trong suốt quá trình phát triển.
- Đảm bảo rằng các yêu cầu được đáp ứng đầy đủ.
BDD là một phương pháp phát triển đáp ứng được các yêu cầu này. BDD giúp:
- Lấy ví dụ về các hành vi mong đợi khác nhau của hệ thống.
- Cho phép viết các ví dụ bằng ngôn ngữ nghiệp vụ, giúp tất cả các bên liên quan, bao gồm cả khách hàng, dễ dàng hiểu được.
- Xác nhận các ví dụ với khách hàng thông qua các cuộc thảo luận thường xuyên.
- Tập trung vào các yêu cầu của khách hàng (thể hiện qua các ví dụ) trong suốt quá trình phát triển.
- Sử dụng các ví dụ làm các bài kiểm thử chấp nhận.
Mục Lục
User Story trong BDD
Trong BDD, việc xác định các hành vi thường được thực hiện thông qua các user story. User story là những mô tả ngắn gọn về một tính năng từ góc độ người dùng. Một user story bao gồm:
- Tiêu đề: Tóm tắt mục đích của user story.
- Tường thuật: Mô tả ai là người dùng, họ muốn gì và tại sao.
- Kịch bản: Mô tả một loạt các kịch bản cụ thể minh họa cách tính năng hoạt động trong các tình huống khác nhau.
Mặc dù BDD không áp đặt một cú pháp hoặc định dạng cụ thể cho user story, nhưng việc chuẩn hóa định dạng là rất quan trọng. Điều này giúp nhóm dễ dàng thảo luận, sửa đổi và tạo ra các user story một cách nhất quán.
Dưới đây là một định dạng user story điển hình được sử dụng trong các dự án BDD, theo đề xuất của Dan North, người được xem là cha đẻ của BDD:
Định dạng User Story điển hình trong BDD
Ví dụ về một user story cụ thể (từ bài viết Giới thiệu BDD của Dan North):
Ví dụ về User Story: Khách hàng rút tiền
Ubiquitous Language – Ngôn Ngữ Chung
BDD nhấn mạnh tầm quan trọng của Ubiquitous Language (Ngôn ngữ chung), một ngôn ngữ tham khảo chung như Domain-Specific Language (DSL). DSL cần được xác định rõ ràng và được thống nhất bởi tất cả các thành viên trong giai đoạn đầu của vòng đời phát triển. DSL giúp dễ dàng giao tiếp về nghiệp vụ của dự án, đồng thời phải đơn giản và đủ mạnh để hỗ trợ thảo luận giữa tất cả các bên liên quan, từ lập trình viên, trưởng nhóm đến khách hàng và các nhà quản lý.
Sử Dụng Công Cụ Chuyên Dụng
BDD được hỗ trợ bởi các công cụ chuyên dụng, giúp tạo và thực thi các bộ kiểm thử. Tương tự như các công cụ kiểm tra tự động được sử dụng trong TDD, các công cụ BDD thực hiện các kiểm thử tự động nhằm mục đích hợp lý hóa quy trình phát triển. Tuy nhiên, sự khác biệt lớn giữa các công cụ TDD và BDD là các công cụ BDD được liên kết chặt chẽ với DSL đã được xác định cho dự án. Các đặc tả kiểm tra trong các công cụ BDD thường sao chép trực tiếp ngôn ngữ và cụm từ từ các user story DSL đã được xác định.
Ví dụ về kịch bản “Account Holder withdraws cash” (Khách hàng rút tiền) của Dan North:
Ví dụ về kịch bản rút tiền trong BDD
Mã kiểm thử (giả mã) cho kịch bản trên sử dụng Ruby và cú pháp Cucumber:
Giả mã kiểm thử kịch bản rút tiền sử dụng Ruby và Cucumber
Ưu Điểm của BDD
- Giảm lỗi hồi quy: Với một bộ kiểm thử đầy đủ được thực hiện liên tục và các kiểm thử mới được bổ sung thường xuyên, BDD giảm đáng kể khả năng xảy ra lỗi hồi quy.
- Cải thiện giao tiếp nhóm: Việc sử dụng ngôn ngữ chung/DSL được xác định rõ ràng giúp cải thiện giao tiếp trong toàn bộ nhóm, hoặc thậm chí giữa các tổ chức, vì mọi người đều sử dụng chung một cấu trúc cho các cụm từ và thuật ngữ khi thảo luận về dự án.
Nhược Điểm của BDD
- Yêu cầu đặc tả trước khi phát triển: BDD yêu cầu nhóm phải viết ra cả DSL và user story cho mỗi kịch bản hoặc tính năng trước khi bắt đầu viết mã. Điều này có thể là một hạn chế đối với nhiều nhóm, đặc biệt là đối với các dự án lớn, hoặc đối với các nhóm nhỏ và các dự án phát triển nhanh, vì nó có thể tốn nhiều công sức hơn.
- Dựa trên phản hồi liên tục từ bên ngoài: Việc giữ liên lạc thường xuyên với người dùng, khách hàng hoặc chuyên gia có thể không phải là vấn đề đối với một số nhóm, nhưng đối với một số tổ chức, việc yêu cầu liên hệ thường xuyên với bên ngoài có thể tác động tiêu cực đến thời gian phát triển. Nếu cần thông tin phản hồi để đưa ra user story hoặc kịch bản mới trước khi kiểm thử được viết, quá trình phát triển có thể bị chậm lại.