Nếu bạn đang tìm hiểu về lĩnh vực phát triển phần mềm thì chắc hẳn sẽ bắt gặp thuật ngữ BDD. Đây là một phương pháp phát triển phần mềm được nhiều lập trình viên quan tâm. Vậy cụ thể BDD là gì? Hãy cùng Hutbuicongnghiep.com tìm hiểu cụ thể qua bài viết dưới đây!
BDD là gì
BDD được viết tắt bởi cụm từ Behavior Driven Development, đây là một quá trình phát triển phần mềm dựa trên phương pháp phát triển phần mềm linh hoạt (phương pháp Agile).
BDD là sự mở rộng của TDD, thay vì tập trung phát triển phần mềm theo hướng kiểm thử. BDD tập trung vào phát triển phần mềm theo hướng hành vi. Quá trình này dựa vào requirement (yêu cầu) các kịch bản test mới được viết dưới dạng ngôn ngữ tự nhiên một cách dễ hiểu nhất. Sau đó thực hiện cài đặt source code để pass qua tất cả các stories.
Cách thức hoạt động của BDD
BDD thường xoay quanh việc thực hiện các bài kiểm thử hành vi hoặc các đặc điểm kỹ thuật chức năng (tài liệu mô tả khả năng, giao diện,…dự kiến của sản phẩm). Điều này nhằm phác thảo các tình huống có thể thực thi cho phần mềm, bao gồm:
- Áp dụng quy tắc 5 Why hoặc kịch bản If – then để tạo User stories và liên hệ rõ ràng những tính năng của ứng dụng với mục đích kinh doanh.
- Xác định kết quả duy nhất của mọi hành vi.
- Biên dịch từng tình huống sang Domain Specific Language (DSL) để đảm bảo giao tiếp một cách chính xác.
- Tập hợp tất cả hành vi vào một bộ tài liệu để tất cả các nhà phát triển, Tester và các bên liên quan khác đều có thể truy cập được.
BDD yêu cầu những bài kiểm thử hành vi phải được tạo trước khi bắt đầu phát triển. Trước khi quá trình phát triển bắt đầu, tất cả các bài kiểm thử hành vi có thể bị thất bại. Tuy nhiên, khi quá trình phát triển sản phẩm diễn ra, nhà phát triển sẽ cấu trúc lại code và các bài kiểm thử đều vượt qua. Khi tất cả vượt qua vòng test, sản phẩm đã sẵn sàng đến bước tiếp theo để hoàn thiện. Tóm lại, vòng đời phát triển của BDD như sau:
- Mô tả hành vi: Mô tả những tính năng của sản phẩm.
- Xác định các yêu cầu: Các yêu cầu được mô hình hóa với những quy tắc kinh doanh của doanh nghiệp.
- Chạy và không hoàn thành bài kiểm tra thử: Chạy test case.
- Cấu trúc lại code: Tái cấu trúc code theo yêu cầu đặt ra.
- Chạy và vượt qua bài kiểm thử: Chạy code đã cập nhật và vượt qua các trường hợp kiểm thử.
Ưu, nhược điểm của BDD
Ưu điểm
Về ưu điểm, BDD hỗ trợ người dùng:
Xác định đúng yêu cầu của khách hàng, giúp lập trình viên đi đúng hướng
Tài liệu dựa theo ngôn ngữ hướng tự nhiên nên bất kỳ đối tượng nào cũng có thể hiểu được. Vì vậy, khi đọc các tài liệu, khách hàng có thể biết được các lập trình viên có đang đáp ứng được kỳ vọng của mình hay không.
Cung cấp thông tin tới tất cả thành viên
BDD được xem là tài liệu “sống” của các dự án và luôn được cập nhật khi có bất kỳ thay đổi nào. Nhờ vậy trong quá trình phát triển dự án, tất cả thành viên đều không bị bỏ lỡ thông tin.
Giảm bớt case không hợp lý
Trong quá trình viết tài liệu dự án, bạn cần có ít nhất một Developer, một QA và một BA. Vì vậy, trước khi bắt đầu thực hiện code có thể thảo luận case nào không thể thực hiện hoặc không hợp lý ở thời điểm hiện tại để cắt bớt.
Giảm lỗi hồi quy nhờ được trang bị đầy đủ bộ kiểm thử liên tục và bộ kiểm thử mới luôn được bổ sung
Vì ở trạng thái kiểm tra liên tục và giám sát, BDD có thể làm giảm đi lỗi hồi quy một cách đáng kể.
Cải thiện giao tiếp trên toàn bộ nhóm hay thậm chí là giữa các tổ chức
Do có cùng một cấu trúc chung cho các cụm từ và thuật ngữ khi thảo luận dự án nên phụ thuộc vào ngôn ngữ hoặc Domain Specific Language phổ biến được xác định rõ ràng có thể giúp cải thiện giao tiếp nhóm hiệu quả hơn.
Nhược điểm
Ngoài các ưu điểm trên, bạn cũng cần chú ý đến một số nhược điểm của BDD để cân nhắc khi sử dụng:
- BDD yêu cầu hiểu sâu về số lượng lớn các khái niệm nên các Developers cần hiểu chi tiết về TDD nếu muốn tiếp cận với BDD.
- Bạn có thể sẽ huỷ BDD nếu cố gắng biến nó thành một kỹ thuật thực hành hoặc kết nối nó với bộ công cụ. Bởi vì trên thực tế, BDD là một khái niệm nên không thể hoạt động như kỹ thuật thực hành.
- Dựa vào các phản hồi liên tục từ bên ngoài: Việc hỗ trợ, giữ liên lạc với khách hàng và chuyên gia có thể không phải là vấn đề đối với một nhóm. Tuy nhiên, với một vài tổ chức, điều này có thể gây ra một số hạn chế và khiến mất nhiều thời gian, công sức để giải quyết các yêu cầu.
So sánh BDD và TDD
| BDD – Behavior Driven Development | TDD – Test Driven Development |
| Tập trung nhiều hơn vào hành vi của ứng dụng và phần mềm. | Tập trung nhiều hơn vào việc triển khai một tính năng của ứng dụng và phần mềm. |
| Những người tham gia là các nhà phát triển, khách hàng và Tester. | Những người tham gia chủ yếu là các nhà phát triển. |
| Cần có sự hợp tác giữa tất cả các bên liên quan. | Chỉ cần có sự hợp tác giữa các nhà phát triển. |
| Tạo ra một thông số kỹ thuật bị lỗi vì tính năng tương ứng không tồn tại. Sau đó, viết code đơn giản có thể làm cho thông số kỹ thuật đáp ứng. Kết quả nhận được hành vi cần thiết được triển khai vào trong hệ thống. | Chủ yếu đề cập đến việc viết một test case không thành công vì chức năng được chỉ định không tồn tại. Sau đó cập nhật code để có thể làm cho test case vượt qua và tính năng sẽ được triển khai trong hệ thống. |
| Trọng tâm chính là các yêu cầu về hệ thống. | Trọng tâm chính là kiểm tra đơn vị. |
| Bắt đầu là một kịch bản. | Bắt đầu là test case |
| Ngôn ngữ được sử dụng để viết hành vi/kịch bản là tiếng Anh đơn giản. | Sử dụng ngôn ngữ lập trình. |
| Được thúc đẩy bởi trải nghiệm của người dùng cuối cùng. | Một cách tiếp cận tốt cho các dự án liên quan đến API và các công cụ bên thứ ba. |
| Một số công cụ được sử dụng đó là Cucumber, Dave, JBehave, Specflow, Concordian, BeanSpec, | Một số công cụ được sử dụng đó là JBehave, JDave, Cucumber, Specflow, BeanSpec, FitNesse,… |
Một số nguyên tắc của phương pháp BDD
Một số nguyên tắc của phương pháp BDD
Việc xác định các hành vi trong BĐ thường được thực hiện thông qua các user story hay còn được gọi là các kịch bản. Nó bao gồm một số tiêu đề cơ sở tóm tắt ý tưởng, một phần tường thuật mô tả ai và những yếu tố cần tham gia trong việc đạt được yêu cầu story này. Bên cạnh đó user story còn bao gồm cả phần kịch bản để mô tả một loạt các kịch bản cụ thể khác.
BDD không thực thi bất kỳ cú pháp hoặc định dạng cụ thể nào đối với user story. Tuy nhiên, BDD đề xuất nên chuyển hóa một số định dạng để tuân theo nhằm đảm bảo nhóm có thể tiếp tục sửa đổi hoặc thảo luận các story một cách dễ dàng. Đồng thời các thành viên trong nhóm cũng có thể tạo ra nhiều story mà không cần làm việc chặt chẽ với nhau.
Trên đây là những kiến thức liên quan đến BDD là gì? Chúc các bạn áp dụng kiến thức vào thực tế để nâng cao hiệu suất làm việc.
Đừng quên ghé thăm hutbuicongnghiep.com để cập nhật bài viết mới thường xuyên nhé.
