Những ai có tìm hiểu về phát triển phần mềm sẽ thấy khái niệm Behaviour Driven Development (BDD) xuất hiện thường xuyên. Đây là một phương pháp phát triển phần mềm đang được nhiều lập trình viên quan tâm và áp dụng. Vậy cụ thể BDD là gì? Bạn hãy cùng Tino Group tìm hiểu cụ thể qua bài viết dưới đây nhé!
Tổng quan về BDD
BDD là gì?
Behaviour Driven Development (BDD) được biết đến là một phương pháp phát triển phần mềm có nguồn gốc từ Test Driven Development (TDD) – mô hình phát triển với trọng tâm hướng về quá trình kiểm thử.
BDD sẽ sử dụng các bài test để minh họa hành vi của hệ thống bằng loại ngôn ngữ dễ đọc, dễ hiểu đối với tất cả mọi người tham gia vào quá trình phát triển. Chẳng hạn như:
- Chuyển đổi thành thông số kỹ thuật thực thi.
- Được sử dụng làm Acceptance test (kiểm thử chấp nhận).
Nhìn chung, đây là một cách tiếp cận tốt trong kiểm thử tự động vì phương pháp này tập trung hơn vào hành vi của hệ thống hơn là việc triển khai code. Trong BDD, tất cả các bên đều tham gia như khách hàng, nhà phát triển, Tester và bên liên quan khác sẽ có một cuộc trò chuyện và xem minh họa hoạt động của hệ thống.
Cụ thể:
- Khách hàng và nhà cung cấp dịch vụ có một cuộc trò chuyện về những gì họ cần.
- Khách hàng, nhà phát triển và Tester cùng nhau giải thích các yêu cầu. Sau đó, các yêu cầu sẽ được xác định trong các kịch bản có cấu trúc.
- Các kịch bản này được Tester sử dụng làm cơ sở cho các bài kiểm thử.
Cách thức hoạt động của BDD
BDD 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ả các khả năng, giao diện, … dự kiến của sản phẩm) 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 nguyên tắc 5 Why hoặc kịch bản If – then để tạo User stories và liên hệ rõ ràng các tính năng của ứng dụng với mục đích kinh doanh.
- Xác định một kết quả duy nhất cho 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 chính xác.
- Tập hợp tất cả cá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 đều có thể truy cập được.
BDD yêu cầu các 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 sẽ thất bại. Nhưng 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ử sẽ vượt qua. Khi tất cả được vượt qua, sản phẩm đã sẵn sàng đến bước kế tiếp để hoàn thiện ra đưa vào sử dụng.
Tóm lại, vòng đời phát triển của BDD như sau:
- Mô tả hành vi: Mô tả các 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 các quy tắt kinh doanh của doanh nghiệp.
- Chạy và không hoàn thành bài kiểm thử: Chạy test case.
- Cấu trúc lại code: Tái cấu trúc code theo yêu cầu.
- Chạy và vượt qua các 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ử.
Những lợi ích của BDD trong phát triển phần mềm
BDD giúp SDLC trở nên đơn giản hơn
SDLC là viết tắt của Software Development Life Cycle, tạm dịch: Vòng đời phát triển phần mềm. Đây là một quá trình từ khi lên ý tưởng đến hoàn thành sản phẩm cho khách hàng. SDLC được coi là tiêu chuẩn cho bất kỳ sự phát triển phần mềm nào. Mặt khác, BDD có đóng góp rất lớn để quá trình SDLC trở nên đơn giản hơn. Cụ thể:
- Việc xác định các yêu cầu và hành vi hệ thống bằng tiếng Anh chuẩn giúp SRS (Software Requirement Specification – Đặc tả yêu cầu phần mềm) trở nên dễ dàng và rõ ràng hơn.
- Mang lại sự cộng tác tốt hơn giữa khách hàng, nhà phát triển và Tester
- Tác động tích cực lớn đến giai đoạn thử nghiệm và triển khai.
Một số lợi ích khác
- Đáp ứng rõ ràng mục tiêu kinh doanh và yêu cầu của khách hàng.
- Giúp xác định các Acceptance Criteria (tiêu chí chấp nhận) trước khi phát triển.
- Tập trung vào hành vi của hệ thống theo quan điểm của khách hàng và nhà phát triển.
- Giúp tránh các tính năng không cần thiết và đảm bảo đầy đủ các tính năng quan trọng.
- Cải thiện mối liên kết trên toàn bộ nhóm và tổ chức
- Hạn chế sửa lỗi sau khi sản phẩm được hoàn thành.
- Tránh hiểu sai trong quá trình phát triển.
- Trở thành tài liệu quan trọng của dự án. Tài liệu luôn được cập nhật khi có bất kỳ thay đổi nào để tất cả thành viên không bị thiếu thông tin trong quá trình phát triển dự án.
So sánh BDD và TDD
TDD là gì?
Test Driven Development (TDD) là kỹ thuật phát triển phần mềm tập trung vào việc triển khai một tính năng của phần mềm. Với kỹ thuật này, test case sẽ được viết trước để xác định những yêu cầu cơ bản trước khi code. Nếu không thành công, nhà phát triển sẽ kiểm tra và cập nhật code để vượt qua test case đã tạo trước đó. Mục đích chính của TDD là giúp quá trình viết code rõ ràng, đơn giản và ít lỗi hơn.
Sự khác biệt giữa BDD và TDD
Dưới đây là bảng so sánh giữa phương pháp BDD và TDD
|
Behavior Driven Development |
Test Driven Development |
|---|---|
|
Tập trung nhiều hơn vào hành vi của ứng dụng, 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, phần mềm |
|
|
|
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 trong hệ thống. |
Chủ yếu nó đề 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à về các yêu cầu 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à ngôn ngữ 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. |
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ụ của bên thứ ba. |
|
Một số công cụ được sử dụng là Cucumber, Dave, JBehave, Spec Flow, Concordian, BeanSpec, |
Một số công cụ được sử dụng là JBehave, JDave, Cucumber, Spec Flow, BeanSpec, FitNesse,… |
Bài viết trên đây đã cung cấp một số thông tin cơ bản của phương pháp BDD trong phát triển phần mềm. Bạn có thể tìm hiểu thêm những kiến thức liên quan đến phương pháp này trong các tài liệu trên internet. Hẹn gặp lại các bạn ở các bài viết thú vị khác của Tino Group nhé!
Những câu hỏi thường gặp
Phương pháp BDD có hạn chế gì không?
Dù mang lại nhiều lợi ích nhưng phương pháp BDD vẫn tồn tại những hạn chế:
- Yêu cầu hiểu sâu về các khái niệm. Trước tiên, bạn cần hiểu rõ về TDD.
- Yêu cầu nhóm viết ra User story cho mỗi kịch bản riêng biệt trước khi viết code. Đối với nhóm nhỏ và dự án phát triển quá gấp sẽ tốn nhiều công sức và khó khăn hơn.
- Giữ liên lạc và tiếp nhận phản hồi liên tục với người dùng, khách hàng.
Quy tắc viết BDD như thế nào?
BDD được viết dưới dạng ngôn ngữ thuần túy gọi là Gherkin. Các quy tắc khi viết Gherkin như sau:
- File được lưu dưới dạng extension là .feature.
- Mỗi file .feature gồm một chức năng duy nhất.
- Mỗi chức năng bao gồm nhiều kịch bản khác nhau với các bước cụ thể.
Phương pháp BDD liên kết với khách hàng như thế nào?
- Lấy ví dụ về các hành vi được mong đợi của hệ thống.
- Cho phép viết các ví dụ thông qua các thuật ngữ nghiệp vụ để đảm bảo mọi người tham gia vào việc phát triển đều hiểu rõ
- Nhận phê duyệt từ khách hàng theo thời gian bằng các cuộc hội thoại.
- Tập trung vào yêu cầu của khách hàng trong suốt quá trình phát triển.
- Sử dụng kiểm thử chấp nhận (Acceptance test)
Phương pháp BDD hay TDD tốt hơn?
BDD ở định dạng dễ đọc hơn đối với mọi bên liên quan vì được viết bằng tiếng Anh. Trong khi với TDD, các trường hợp kiểm thử được viết bằng các ngôn ngữ lập trình như Ruby và Java. BDD giải thích hành vi của một ứng dụng cho người dùng cuối trong khi TDD tập trung vào cách chức năng được triển khai.
CÔNG TY CỔ PHẦN TẬP ĐOÀN TINO
- Trụ sở chính: L17-11, Tầng 17, Tòa nhà Vincom Center, Số 72 Lê Thánh Tôn, Phường Bến Nghé, Quận 1, Thành phố Hồ Chí Minh
Văn phòng đại diện: 42 Trần Phú, Phường 4, Quận 5, Thành phố Hồ Chí Minh - Điện thoại: 0364 333 333
Tổng đài miễn phí: 1800 6734 - Email: sales@tino.org
- Website: www.tino.org