Phương pháp phát triển theo hướng kiểm thử cho phát triển phần mềm Agile

Hiện nay, mọi người thường nói về phát triển Agile.

Phát triển Agile là gì?

Phát triển Agile là khả năng phát triển phần mềm đáp ứng nhu cầu thay đổi nhanh chóng. Tên gọi, khái niệm, quy trình và thuật ngữ cụ thể của chúng khác nhau. So với “không Agile,” họ nhấn mạnh sự hợp tác chặt chẽ giữa các nhóm lập trình viên và các chuyên gia kinh doanh, giao tiếp trực tiếp (được coi là hiệu quả hơn so với tài liệu viết), và thường xuyên phát hành các phiên bản phần mềm mới, nhỏ và các nhóm tự tổ chức cho việc viết các tính năng nhỏ và có giá trị, và các phương pháp tổ chức nhóm thích ứng với nhu cầu thay đổi, với sự chú trọng lớn hơn vào vai trò của con người trong phát triển phần mềm.

Tuy nhiên, có một số phiên bản tương tự của các phương pháp phát triển Agile TDD, chẳng hạn như TDD: BDD, DDD và ATDD. Hãy để tôi giới thiệu ngắn gọn về các phương pháp này trước khi giới thiệu TDD một cách chi tiết:

TDD: Phát triển theo hướng kiểm thử

Phát triển theo hướng kiểm thử (TDD) là một quy trình phát triển phần mềm, dựa vào việc chuyển đổi yêu cầu phần mềm thành các trường hợp kiểm thử trước khi phần mềm được phát triển hoàn toàn, và theo dõi toàn bộ quá trình phát triển phần mềm bằng cách kiểm thử phần mềm nhiều lần cho tất cả các trường hợp kiểm thử. Điều này trái ngược với việc phát triển phần mềm trước và sau đó tạo ra các trường hợp kiểm thử. Một số mô hình phổ biến hỗ trợ TDD rất tốt, chẳng hạn như MVC và MVP.

BDD: Phát triển theo hướng hành vi (Behavior Driven Development)

Phát triển theo hướng hành vi (BDD) cũng là một quy trình phát triển phần mềm Agile. Nó khuyến khích sự hợp tác giữa các nhà phát triển, kiểm thử viên đảm bảo chất lượng và đại diện khách hàng trong các dự án phần mềm. Nó khuyến khích các nhóm sử dụng các cuộc trò chuyện và ví dụ cụ thể để hình thành một sự hiểu biết chung về cách ứng dụng nên hoạt động. Nó xuất phát từ phát triển theo hướng kiểm thử (TDD).

ATDD: Phát triển theo hướng kiểm thử chấp nhận

Để thúc đẩy việc hiện thực hóa mã chức năng thông qua các trường hợp kiểm thử đơn vị, nhóm cần xác định các tiêu chuẩn chất lượng mong đợi và các quy tắc chấp nhận, và thúc đẩy thực hành TDD của các nhà phát triển và hiệu suất của các kiểm thử viên thông qua một kế hoạch kiểm thử chấp nhận rõ ràng và nhất quán (bao gồm một loạt các kịch bản kiểm thử). Đối với các nhà phát triển, nó nhấn mạnh cách thực hiện hệ thống và cách kiểm thử nó.

DDD: Thiết kế theo hướng miền

DDD đề cập đến thiết kế theo hướng miền, tức là phát triển theo hướng miền. DDD thực sự được xây dựng trên nền tảng này vì nó tập trung vào thiết kế lớp dịch vụ, tập trung vào việc thực hiện kinh doanh, kết hợp phân tích và thiết kế, và không còn giữ nó trong trạng thái phân chia, nhằm thực hiện đúng và toàn diện các nhu cầu của khách hàng và xây dựng một mô hình khả năng mở rộng kinh doanh.

Kế hoạch thực hiện TDD

Thông qua kiểm thử để thúc đẩy toàn bộ phát triển, nhưng phát triển theo hướng kiểm thử không chỉ là một công việc kiểm thử đơn giản, mà là một quy trình định lượng phân tích yêu cầu, thiết kế và kiểm soát chất lượng.

Nguyên tắc phát triển

Viết mã kiểm thử trước, sau đó viết mã cho chức năng.

1. Viết mã kiểm thử theo tài liệu yêu cầu, không phải để hiện thực hóa chức năng;
2. Đừng muốn ăn một miếng lớn. Khi kiểm thử các khối chức năng lớn, bạn nên chia chúng thành các khối chức năng nhỏ hơn để kiểm thử;
3. Nhớ không viết mã để hoàn thành chức năng, hãy sử dụng mã đơn giản nhất có thể để thực hiện chức năng;
4. Nếu các yêu cầu có thể được kiểm thử, hãy viết mã kiểm thử, và từ bỏ những yêu cầu không thể kiểm thử hoặc cảm thấy không cần kiểm thử;
5. Trước khi thay đổi/thêm bất kỳ mã chức năng nào, bạn phải suy nghĩ xem có muốn thay đổi/thêm các trường hợp kiểm thử hay không;
6. Mã chức năng/kiểm thử, cấu trúc không hợp lý, mã trùng lặp, v.v., hãy tái cấu trúc kịp thời sau khi kiểm thử thành công.

Quy trình phát triển TDD

1. Phân tích và xác định một kịch bản kiểm thử mục tiêu;
2. Thêm một kiểm thử đơn vị để xác minh đầu vào và đầu ra của kịch bản kiểm thử;
3. Chạy kiểm thử và nhận kết quả kiểm thử thất bại;
4. Viết mã chức năng đơn giản nhất để vượt qua kiểm thử;
5. Chạy kiểm thử một lần nữa và thấy rằng kiểm thử thành công;
6. Tiến hành tái cấu trúc mã, bao gồm mã chức năng và mã kiểm thử đơn vị;
7. Lặp lại các bước trên cho đến khi phát triển hoàn tất.

Lợi ích của TDD

1. Giảm bớt gánh nặng cho các nhà phát triển. Thông qua một quy trình rõ ràng, cho phép chúng ta tập trung vào chỉ một điểm tại một thời điểm, và gánh nặng suy nghĩ sẽ ít hơn.
2. Mạng lưới bảo vệ. Việc bao phủ kiểm thử đơn vị hoàn chỉnh cung cấp một mạng lưới bảo vệ cho mã sản phẩm, giúp dễ dàng đáp ứng các thay đổi trong yêu cầu hoặc cải thiện thiết kế mã. Vì vậy, nếu yêu cầu dự án của bạn ổn định, hoàn thành một lần và không có thay đổi nào sau đó, lợi ích của TDD sẽ ít hơn.
3. Làm rõ yêu cầu trước. Việc viết kiểm thử trước có thể giúp chúng ta suy nghĩ về các yêu cầu và làm rõ các chi tiết của yêu cầu trước, thay vì phát hiện ra các yêu cầu không rõ ràng chỉ khi đang viết mã.
4. Phản hồi nhanh. Nhiều người nói rằng khi TDD, khối lượng mã của tôi tăng lên, vì vậy hiệu suất phát triển giảm. Tuy nhiên, nếu bạn không có kiểm thử đơn vị, bạn phải kiểm thử chúng thủ công, bạn sẽ tốn nhiều thời gian chuẩn bị dữ liệu, khởi động ứng dụng, sửa đổi giao diện, v.v., và phản hồi sẽ chậm. Để chính xác, phản hồi nhanh là một lợi ích của kiểm thử đơn vị.