MVC - Đơn vị kiểm tra những thứ sai?

Question

Trong khi thực hành một số TDD tại nơi làm việc cho dự án ASP.Net MVC, tôi gặp phải một số tình huống khi tôi viết bài kiểm tra để đảm bảo rằng các hành động cụ thể trả về các quan điểm chính xác hoặc có các thuộc tính cụ thể trên chúng ([ChildActionOnly] vv). (trên thực tế, tôi đã tìm thấy một số bài viết thú vị ở đây SO về các phương pháp mở rộng hữu ích để giúp đạt được điều này).

Khi tôi lần đầu tiên được giới thiệu khái niệm kiểm tra đơn vị và TDD khi tham gia khóa học cách đây vài năm, sự nhấn mạnh dựa trên các bài kiểm tra nên tập trung vào logic thử nghiệm đằng sau các tính năng và chức năng mong muốn của người dùng - dự án cốt lõi 'yêu cầu' nếu bạn muốn.

Câu hỏi của tôi là - nếu đây là trường hợp, kiểm tra xem có đúng tập tin xem hay hành động có thuộc tính cụ thể không thực sự bao gồm phương pháp kiểm tra đơn vị? Tôi có viết bài kiểm tra vì những lý do sai (tức là bảo vệ bản thân mình và các đồng nghiệp khác không mắc lỗi tái cấu trúc) hay là những trường hợp kiểm tra đơn vị có giá trị hợp lệ này?

Answer 1

Nếu phương thức xử lý có thể trả về một trong hai (hoặc nhiều) chế độ xem tùy thuộc vào một số logic thì kiểm tra đơn vị xác nhận xem chính xác sẽ hữu ích. Cùng đi cho một phương pháp xử lý mà chèn các thuộc tính cụ thể tùy thuộc vào logic.

Am Tôi viết bài kiểm tra vì những lý do sai (ví dụ đơn giản là bảo vệ đồng nghiệp khác từ làm cho một sai lầm tái cấu trúc) hoặc là những trường hợp này hợp lệ của đơn vị xét nghiệm có giá trị?

Lỗi hồi quy bắt được là một trong những lợi ích của kiểm tra đơn vị, đặc biệt hữu ích khi tái cấu trúc. Nếu bạn vô tình thay đổi chế độ xem được trả lại trong khi thực hiện một số phép tái cấu trúc sẽ rất hữu ích để bắt đầu sớm - thay vì chờ đợi một thử nghiệm chỉ chạy khi ứng dụng được chạy.

Answer 2

Nếu hành động của bạn trả về các chế độ xem khác nhau (hoặc kết quả hành động) tùy thuộc vào một số logic. Viết một bài kiểm tra.

Nếu bạn luôn trả về View() thì không.

Nếu bạn trả lại chế độ xem có tên khác với tên của hành động - thì bạn có thể tranh luận rằng bạn nên viết bài kiểm tra.

Answer 3

Điều đó tùy thuộc. Để sử dụng một trong các ví dụ của bạn: Kiểm tra xem hành động có thuộc tính cụ thể không, nhưng đó là tốt hơn để viết kiểm tra xác minh hành vi hoạt động như mong đợi, điều đó sẽ thất bại nếu thuộc tính bị thiếu.

Điều đó nói rằng, cuối cùng các thử nghiệm của bạn là một mạng lưới an toàn. Nếu nó có một cơ hội hợp lý để ngăn chặn một lỗi từ trượt tại một số điểm trong tương lai, nó đang làm công việc của mình.

Nếu đó là một thử nghiệm đơn giản có chi phí thấp và ít cơ hội phá vỡ tùy ý trong tương lai, hãy thực hiện. Tôi muốn có quá nhiều bài kiểm tra quá ít.

Answer 4

Thật vậy, các thử nghiệm của bạn phải kiểm tra logic của bạn. Điều đó không nên biến mất. Tuy nhiên, lý tưởng là bạn nên viết kiểm tra cho bất cứ điều gì có thể đi sai. Ví dụ, bảo đảm rằng tất cả các phương thức cần được bảo mật đều có thuộc tính Authorize thích hợp. Đây là một thử nghiệm an ninh.

Cuối cùng, bạn quyết định điều gì hữu ích để bạn kiểm tra.