Có khu vực nào TDD cung cấp ROI cao và các khu vực khác mà ROI thấp đến mức không đáng để theo dõi không? [đóng cửa]

Hướng phát triển thử nghiệm. Tôi hiểu rồi, thích nó.

Nhưng bài kiểm tra viết không yêu cầu chi phí. Vì vậy, TDD nên được sử dụng phổ biến trong toàn bộ cơ sở mã, hoặc có những khu vực mà TDD cung cấp ROI cao và các khu vực khác mà ROI thấp đến mức không đáng để theo dõi.

Tôi muốn nói tránh TDD ở những nơi mà mã có thể thay đổi nhiều về cấu trúc. Tức là, thật tuyệt khi có một đống bài kiểm tra cho một phương pháp mà chữ ký hiếm khi thay đổi nhưng được tái cấu trúc nội bộ thường xuyên hơn, nhưng thật khó để sửa các bài kiểm tra của bạn mỗi khi giao diện biến động mạnh thay đổi đáng kể.

Các ứng dụng tôi đang làm việc gần đây là các ứng dụng web dựa trên dữ liệu được xây dựng trên Gui-> Presenter-> BusinessLogic-> Kiến trúc dựa trên lớp truy cập dữ liệu. Lớp truy cập dữ liệu của tôi được kiểm tra như doanh nghiệp của không ai. Lớp logic kinh doanh được thử nghiệm khá tốt. Trình bày chỉ được thử nghiệm ở các khu vực ổn định hơn và GUI, được thay đổi hàng giờ, gần như không có thử nghiệm.

Tôi đề nghị viết một bộ kiểm tra đầy đủ trong các lĩnh vực mà nó hợp lý và thực tế để làm. Trong các lĩnh vực ít thực tế, viết kiểm tra vệ sinh.

Theo kinh nghiệm của tôi, phần lớn các trường hợp kiểm thử đầy đủ chắc chắn có giá trị trong hầu hết các trường hợp, nhưng thực tế bảo hiểm mã có lợi nhuận giảm dần. Tại một số điểm, viết nhiều bài kiểm tra chỉ để tăng độ bao phủ mã không có ý nghĩa.

Ví dụ, tùy thuộc vào ngôn ngữ / công nghệ của bạn, việc kiểm tra giao diện người dùng có thể không thực tế hoặc thậm chí không khả thi. Rất nhiều bài kiểm tra có thể sẽ dựa vào những gì người dùng nhìn thấy và không thể tự động hóa. Làm thế nào bạn có thể kiểm tra rằng một phương thức để tạo một hình ảnh xác thực tạo ra một hình ảnh mà con người có thể đọc được chẳng hạn?

Nếu một bộ kiểm tra hoàn chỉnh sẽ khiến bạn mất ba ngày để viết, khả năng lỗi được đưa vào thành phần đó trong bản nhạc là rất thấp và bản thân hàm chỉ mất nửa giờ để viết, có lẽ bạn nên suy nghĩ kỹ về việc thời gian đó có đáng không Có lẽ chỉ cần viết một kiểm tra vệ sinh cơ bản cho chức năng đó sẽ cung cấp giá trị?

Lời khuyên chung của tôi là bạn nên kiểm tra các thành phần đầy đủ trong đó các bài kiểm tra có thể được viết tương đối dễ dàng. Tuy nhiên, nếu đó là một khu vực rất khó kiểm tra, hãy vẽ một đường thẳng trên cát và viết các bài kiểm tra sẽ kiểm tra khu vực đó ở mức cao hơn thay vì kiểm tra đầy đủ.

Trong ví dụ captcha trước đó, có thể viết các bài kiểm tra kiểm tra hình ảnh có kích thước và định dạng chính xác được trả về và không có ngoại lệ nào được đưa ra. Điều đó cung cấp cho bạn một số mức độ đảm bảo mà không cần quá nhiệt tình.

Đối với tôi, TDD không phải là chi phí. Đó chỉ là cách tôi viết mã. Tại sao bạn nói rằng bài kiểm tra viết là "trên không"? Đó chỉ là một phần của quá trình. Quan điểm của tôi là gỡ lỗi là chi phí hoạt động và đó là hoạt động mà về cơ bản tôi đã ngừng thực hiện khi bắt đầu TDD-ing. Trước TDD, gỡ lỗi là một phần không thể thiếu trong quá trình viết phần mềm của tôi.

Tôi nghĩ rằng từ bỏ gỡ lỗi để viết bài kiểm tra là một món hời rất tốt.

Một nơi mà TDD thực sự khó khăn là khi kiểm tra lượt xem trong ứng dụng MVC.

Vì bạn đang kiểm tra một hàm trả về một chuỗi html béo, nên bạn bị mắc kẹt khi phân tích cú pháp html chỉ để xem liệu mọi thứ có hoạt động không. Hơn nữa, nó có thể trở thành một cơn ác mộng duy trì. Một ngày bạn di chuyển một hộp kiểm xung quanh và kaboom, bài kiểm tra của bạn bị hỏng.

Tôi thích TDD cho rất nhiều thử nghiệm của tôi, nhưng nó không phải là công cụ duy nhất trong vành đai lập trình viên.