Tôi đã ở trong nhiều nhóm cố gắng thực hành các phương pháp Agile và thường các nhóm này là trung tâm kiểm tra. Việc kiểm tra có phải là một phần cần thiết khi thực hành phương pháp Agile hay đây chỉ là một thực hành XP đã được áp dụng trong nhiều năm qua?

Kiểm tra là hoàn toàn cần thiết để nhanh nhẹn, chủ yếu vì nhanh nhẹn dựa trên các cải tiến gia tăng: khó khăn là đôi khi khó có thể thấy các thay đổi hiện tại sẽ ảnh hưởng đến mã cũ của bạn như thế nào. Cách tốt nhất để tự tin rằng bạn chưa phá vỡ thứ gì đó là kiểm tra nó và biết CÁCH kiểm tra nó. Bằng cách đó, bạn tìm thấy lỗi ngay lập tức, không phải xuống đường khi bạn quên chính xác những gì bạn đã làm khi bạn đang viết mã đã phá vỡ một số tính năng cũ.

Lý do điều này khác với lập trình kiểu thiết kế từ trên xuống truyền thống hơn là vì trong môi trường đó, a) rất khó kiểm tra cho đến khi bạn có sản phẩm hoàn chỉnh b) về lý thuyết bạn đang xem xét tất cả các tiêu chí thiết kế cùng một lúc, và do đó bạn ít có khả năng đưa ra quyết định thiết kế phá vỡ các quyết định thiết kế trước đó.

Có lẽ bạn đang nói về kiểm thử tự động, kiểm tra đơn vị, kiểm tra tích hợp, v.v ... Đây là những điều quan trọng để nhanh nhẹn hơn kiểm tra thủ công (với người kiểm tra và như vậy) vì chúng quá chậm, do đó không thể kiểm tra mọi thay đổi nhỏ mà bạn thực hiện. Vì agile là về các bước lặp nhỏ nhanh, nên có các bài kiểm tra xác minh tính chính xác trong vài giây hoặc vài phút, thay vì hàng giờ hoặc nhiều ngày, rất hữu ích.

Nếu bạn không có bài kiểm tra, làm sao bạn biết mã của bạn hoạt động?

Chỉnh sửa: xác nhận rằng các kiểm tra không thể chứng minh rằng mã hoạt động không xác định một thuật ngữ quan trọng, cụ thể là hoạt động . Nó có nghĩa gì cho một chương trình để làm việc? Nếu bạn giữ thuật ngữ này mơ hồ, thì không có cách nào để chứng minh hoặc chắc chắn rằng bất kỳ chương trình nào hoạt động. Không bao giờ.

Mặt khác, bạn có thể định nghĩa các tác phẩm là "hành xử theo một đặc điểm kỹ thuật". Bây giờ bạn không chỉ có thể sử dụng các thử nghiệm để cho thấy mã hoạt động, mà chính các thử nghiệm có thể đóng vai trò là một đặc tả thực thi cho hành vi của mã của bạn. Nói cách khác, một bộ kiểm tra viết tốt xác định ý nghĩa của công việc .

Cách suy nghĩ này cũng buộc bạn phải kiểm tra lại ý nghĩa của một lỗi . Nếu mã của bạn vượt qua tất cả các bài kiểm tra, thì không có lỗi trong mã. Nếu, mặc dù vậy, hệ thống không hoạt động như bình thường, thì hành vi của nó không được chỉ định chính xác. I E. lỗi là trong thông số kỹ thuật, được xác định bởi các bài kiểm tra.

Cách tiếp cận phát triển phần mềm này tách rời đặc tả chức năng của một hệ thống từ việc triển khai nó, mà theo mọi cuốn sách kỹ thuật phần mềm trên thế giới, là một điều rất tốt. Đồng thời, cách tiếp cận này đảm bảo rằng việc triển khai của bạn luôn tương ứng với thông số chức năng.

Không, nó không cần thiết"

Các nguyên tắc của Agile không nói gì trực tiếp về thử nghiệm.

Nhưng nó rất được khuyến khích

Với cam kết của Agile về một quy trình bền vững, phân phối liên tục / tăng dần và chất lượng phần mềm, kiểm tra tự động là giải pháp tốt nhất hiện có cho hầu hết các dự án

Các ngoại lệ (như được lưu ý bởi Jörg W Mittag) bao gồm các công cụ phát triển có thể chứng minh chính xác, các hệ thống lập trình meta tạo mã, et al. Nhưng những loại hệ thống này rất hiếm.

Cả Agile và XP đều cố gắng tránh Big Design Up Front . Trong BDUF, các yêu cầu được thu thập, một đặc tả chính thức được tạo ra, sau đó mã hóa được thực hiện, sau đó thử nghiệm được thực hiện. Điều này có ý nghĩa đối với các hệ thống quan trọng, nhiệm vụ và quan trọng trong cuộc sống như thiết bị y tế, tàu thăm dò không gian, v.v.

Agile tránh luồng này vì nó không hoạt động tốt đối với các sự cố không được xác định rõ, ví dụ: "bất kỳ thay đổi nào khách hàng yêu cầu trong tuần này". Chúng tôi vẫn cần một đặc điểm kỹ thuật chính thức, vì vậy chúng tôi biết phải làm gì và khi nào chúng tôi hoàn thành, nhưng thay vì một số loại tài liệu bằng văn bản, chúng tôi sử dụng mã dưới dạng thử nghiệm tự động.

Kiểm tra đơn vị tự động là viết nhanh, chạy nhanh và rất mô-đun / tách rời. Điều này làm cho họ một cách nhanh chóng để chính thức xác định và kiểm tra các yêu cầu.