BDD - Phát triển theo hướng thử nghiệm
Khi bạn xem bất kỳ tài liệu tham khảo nào về Phát triển theo hướng hành vi, bạn sẽ thấy cách sử dụng các cụm từ như “BDD bắt nguồn từ TDD”, “BDD và TDD”. Để biết BDD ra đời như thế nào, tại sao nó được cho là có nguồn gốc từ TDD và BDD và TDD là gì, bạn phải hiểu về TDD.
Tại sao phải thử nghiệm?
Để bắt đầu, chúng ta hãy đi vào các nguyên tắc cơ bản của thử nghiệm. Mục đích của thử nghiệm là để đảm bảo rằng hệ thống được xây dựng đang hoạt động như mong đợi. Hãy xem xét ví dụ sau.
Do đó, bằng kinh nghiệm, chúng tôi đã học được rằng việc phát hiện ra một khiếm khuyết và khi nó được đưa ra và sửa chữa nó ngay lập tức sẽ có hiệu quả về chi phí. Do đó, có sự cần thiết của việc viết các trường hợp kiểm thử ở mọi giai đoạn phát triển và kiểm thử. Đây là điều mà các phương pháp kiểm tra truyền thống đã dạy chúng tôi, thường được gọi là Thử nghiệm sớm.
Cách tiếp cận kiểm tra này được gọi là cách tiếp cận Kiểm tra-Cuối cùng vì kiểm tra được thực hiện sau khi hoàn thành một giai đoạn.
Những thách thức với Phương pháp tiếp cận thử nghiệm-lần cuối
Cách tiếp cận Kiểm tra-Cuối cùng đã được theo sau trong một thời gian dài trong các dự án phát triển phần mềm. Tuy nhiên, trên thực tế, với cách tiếp cận này, vì quá trình thử nghiệm phải đợi cho đến khi giai đoạn cụ thể hoàn thành, nên nó thường bị bỏ qua vì -
Sự chậm trễ trong việc hoàn thành giai đoạn.
Thời gian biểu chặt chẽ.
Tập trung vào việc giao hàng đúng giờ, bỏ qua khâu kiểm tra.
Hơn nữa, trong cách tiếp cận Kiểm tra-Cuối cùng, Kiểm thử đơn vị, được cho là do các nhà phát triển thực hiện thường bị bỏ qua. Các lý do khác nhau được tìm thấy dựa trên tư duy của các nhà phát triển -
Họ là nhà phát triển chứ không phải người thử nghiệm.
Kiểm tra là trách nhiệm của những người kiểm tra.
Chúng hiệu quả trong việc mã hóa và mã của chúng sẽ không có lỗi.
Điều này dẫn đến -
Thỏa hiệp về chất lượng của sản phẩm được giao.
Chỉ có trách nhiệm giải trình về chất lượng cho người kiểm tra.
Chi phí cao trong việc sửa chữa các lỗi, chuyển phát sau.
Không có khả năng đạt được sự hài lòng của khách hàng, điều này cũng có nghĩa là mất công việc kinh doanh lặp lại, do đó ảnh hưởng đến uy tín.
Những yếu tố này đã kêu gọi sự thay đổi mô hình, để tập trung vào thử nghiệm. Kết quả là phương pháp Thử nghiệm Đầu tiên.
Phương pháp tiếp cận thử nghiệm đầu tiên
Cách tiếp cận Test-First thay thế cách phát triển từ trong ra ngoài (viết mã và sau đó kiểm tra) thành cách phát triển từ ngoài vào trong (viết thử nghiệm và sau đó viết mã).
Cách tiếp cận này được kết hợp vào các phương pháp luận phát triển phần mềm sau (cũng là Agile) -
eXtreme Programming (XP).
Test Driven Dsự phát triển (TDD).
Trong các phương pháp luận này, nhà phát triển thiết kế và viết các bài kiểm tra Đơn vị cho một mô-đun mã trước khi viết một dòng duy nhất của mô-đun mã. Sau đó, nhà phát triển tạo mô-đun mã với mục tiêu vượt qua bài kiểm tra Đơn vị. Do đó, các phương pháp này sử dụng Unit testing để thúc đẩy sự phát triển.
Điểm cơ bản cần lưu ý rằng mục tiêu là phát triển dựa trên thử nghiệm.
Red-Green-Refactor chu kỳ
Test Driven Development được sử dụng để phát triển mã được hướng dẫn bởi Unit tests.
Step 1 - Hãy xem xét một mô-đun mã sẽ được viết.
Step 2 - Viết bài kiểm tra
Step 3 - Chạy thử nghiệm.
Kiểm tra không thành công, vì mã vẫn chưa được viết. Do đó, Bước 2 thường được gọi là viết một bài kiểm tra không đạt.
Step 4 - Viết mã tối thiểu có thể để vượt qua bài kiểm tra.
Step 5- Chạy tất cả các bài kiểm tra để đảm bảo rằng tất cả chúng vẫn vượt qua. Các bài kiểm tra đơn vị được tự động hóa để hỗ trợ bước này.
Step 6 - Trình tái cấu trúc.
Step 7 - Lặp lại Bước 1 đến Bước 6 cho mô-đun mã tiếp theo.
Mỗi chu kỳ phải rất ngắn và một giờ điển hình nên chứa nhiều chu kỳ.
Điều này còn được gọi phổ biến là Red-Green-Refactor chu kỳ, nơi -
Red - Viết bài kiểm tra không đạt.
Green - Viết mã để vượt qua bài kiểm tra.
Refactor - Loại bỏ sự trùng lặp và cải tiến mã theo các tiêu chuẩn được chấp nhận.
Các bước xử lý TDD
Các bước của quy trình TDD được minh họa bên dưới.
Ưu điểm của TDD
Các lợi ích hoặc lợi thế của Phát triển theo hướng kiểm tra là:
Trước tiên, nhà phát triển cần phải hiểu kết quả mong muốn là gì và cách kiểm tra nó trước khi tạo mã.
Mã cho một thành phần chỉ được hoàn thành khi quá trình kiểm tra vượt qua và mã được cấu trúc lại. Điều này đảm bảo thử nghiệm và cấu trúc lại trước khi nhà phát triển chuyển sang thử nghiệm tiếp theo.
Khi bộ bài kiểm tra Đơn vị được chạy sau mỗi lần tái cấu trúc, phản hồi rằng mỗi thành phần vẫn hoạt động là không đổi.
Bài kiểm tra Đơn vị hoạt động như một tài liệu sống luôn cập nhật dữ liệu.
Nếu một lỗi được tìm thấy, nhà phát triển sẽ tạo một bài kiểm tra để tiết lộ lỗi đó và sau đó sửa đổi mã để bài kiểm tra vượt qua và lỗi được sửa. Điều này làm giảm thời gian gỡ lỗi. Tất cả các bài kiểm tra khác cũng được chạy và khi chúng vượt qua, nó đảm bảo rằng chức năng hiện có không bị hỏng
Nhà phát triển có thể đưa ra quyết định thiết kế và cấu trúc lại bất kỳ lúc nào và việc chạy thử nghiệm đảm bảo rằng hệ thống vẫn hoạt động. Điều này làm cho phần mềm có thể bảo trì được.
Nhà phát triển có thể tự tin thực hiện bất kỳ thay đổi nào vì nếu thay đổi ảnh hưởng đến bất kỳ chức năng hiện có nào, điều tương tự sẽ được tiết lộ bằng cách chạy thử nghiệm và các lỗi có thể được sửa ngay lập tức.
Trên mỗi lần chạy thử nghiệm liên tiếp, tất cả các bản sửa lỗi trước đó cũng được xác minh và giảm sự lặp lại của cùng một lỗi.
Vì hầu hết các thử nghiệm được thực hiện trong quá trình phát triển, nên việc thử nghiệm trước khi giao hàng được rút ngắn.
Nhược điểm của TDD
Điểm khởi đầu là Câu chuyện người dùng, mô tả hành vi của hệ thống. Do đó, các nhà phát triển thường gặp phải những câu hỏi sau:
Kiểm tra khi nào?
Kiểm tra những gì?
Làm thế nào để biết nếu một thông số kỹ thuật được đáp ứng?
Mã có mang lại giá trị kinh doanh không?
Những quan niệm sai lầm về TDD
Những quan niệm sai lầm sau đây tồn tại trong ngành và cần được làm rõ.
| Quan niệm sai lầm | Làm rõ |
|---|---|
| TDD là tất cả về thử nghiệm và tự động hóa thử nghiệm. | TDD là một phương pháp phát triển sử dụng cách tiếp cận Test-First. |
| TDD không liên quan đến bất kỳ thiết kế nào. | TDD bao gồm phân tích quan trọng và thiết kế dựa trên các yêu cầu. Thiết kế xuất hiện trong quá trình phát triển. |
| TDD chỉ ở mức Đơn vị. | TDD có thể được sử dụng ở cấp độ tích hợp và hệ thống. |
| TDD không thể được sử dụng bởi các dự án thử nghiệm truyền thống. | TDD trở nên phổ biến với Lập trình cực đoan và đang được sử dụng trong các phương pháp luận Agile khác. Tuy nhiên, nó cũng có thể được sử dụng trong các dự án thử nghiệm truyền thống. |
| TDD là một công cụ. | TDD là một phương pháp phát triển và sau khi mỗi Bài kiểm tra đơn vị mới vượt qua, nó sẽ được thêm vào Bộ kiểm tra tự động hóa vì tất cả các bài kiểm tra cần được chạy bất cứ khi nào mã mới được thêm vào hoặc mã hiện có được sửa đổi và sau mỗi lần tái cấu trúc. Do đó, các Công cụ Tự động hóa Kiểm tra hỗ trợ TDD tạo điều kiện thuận lợi cho quá trình này. |
| TDD có nghĩa là giao các bài kiểm tra Chấp nhận cho các nhà phát triển. | TDD không có nghĩa là giao Kiểm tra chấp nhận cho nhà phát triển. |
Chấp nhận TDD
Phát triển theo hướng kiểm tra chấp nhận (ATDD) xác định Tiêu chí chấp nhận và Kiểm tra chấp nhận trong quá trình tạo Câu chuyện người dùng, trong giai đoạn đầu phát triển. ATDD tập trung vào sự giao tiếp và hiểu biết chung giữa khách hàng, nhà phát triển và người thử nghiệm.
Các thực hành chính trong ATDD như sau:
Thảo luận về các tình huống trong thế giới thực để xây dựng sự hiểu biết chung về miền.
Sử dụng các tình huống đó để đạt được tiêu chí chấp nhận.
Tự động hóa các bài kiểm tra Chấp nhận.
Tập trung sự phát triển vào các bài kiểm tra đó.
Sử dụng các bài kiểm tra như một thông số kỹ thuật trực tiếp để tạo điều kiện thay đổi.
Các lợi ích của việc sử dụng ATDD như sau:
Yêu cầu rõ ràng và không có khoảng cách chức năng.
Những người khác hiểu những trường hợp đặc biệt mà các nhà phát triển thấy trước.
Các bài kiểm tra Chấp nhận hướng dẫn sự phát triển.
TDD Vs BDD
Theo Dan North, các lập trình viên thường gặp phải các vấn đề sau khi thực hiện Phát triển theo hướng kiểm tra -
Bắt đầu từ đâu
Kiểm tra những gì và không nên kiểm tra
Kiểm tra bao nhiêu trong một lần
Bài kiểm tra của họ được gọi là gì
Làm thế nào để hiểu tại sao một bài kiểm tra không thành công
Giải pháp cho tất cả những vấn đề này là Phát triển theo hướng hành vi. Nó đã phát triển dựa trên các phương pháp thực hành nhanh đã được thiết lập và được thiết kế để làm cho chúng dễ tiếp cận và hiệu quả hơn cho các nhóm, mới đối với phân phối phần mềm nhanh. Theo thời gian, BDD đã phát triển để bao quát bức tranh rộng hơn về phân tích nhanh và kiểm thử chấp nhận tự động.
Chính difference between TDD and BDD đó là -
TDD mô tả cách hoạt động của phần mềm.
Mặt khác, BDD -
Mô tả cách người dùng cuối sử dụng phần mềm.
Thúc đẩy sự hợp tác và giao tiếp.
Nhấn mạnh vào các ví dụ về hành vi của Hệ thống.
Nhắm đến các đặc tả thực thi được lấy từ các ví dụ