Tại sao thử nghiệm MVC Views lại nhăn mặt?

23

Tôi hiện đang đặt nền tảng cho một ứng dụng ASP.Net MVC và tôi đang xem xét loại bài kiểm tra đơn vị nào tôi nên chuẩn bị để viết. Tôi đã thấy ở nhiều nơi về cơ bản mọi người nói rằng 'đừng bận tâm kiểm tra quan điểm của bạn, không có logic và nó tầm thường và sẽ được bao phủ bởi một bài kiểm tra tích hợp'.

Tôi không hiểu làm thế nào điều này đã trở thành sự khôn ngoan được chấp nhận. Kiểm tra tích hợp phục vụ một mục đích hoàn toàn khác so với kiểm tra đơn vị. Nếu tôi phá vỡ một cái gì đó, tôi không muốn biết nửa giờ sau khi các bài kiểm tra tích hợp của tôi bị hỏng, tôi muốn biết ngay lập tức.

Kịch bản mẫu: Hãy nói rằng chúng tôi đang xử lý một ứng dụng CRUD tiêu chuẩn với thực thể Khách hàng. Khách hàng có tên và địa chỉ. Ở mỗi cấp độ thử nghiệm, tôi muốn xác minh rằng logic truy xuất của Khách hàng có được cả tên và địa chỉ chính xác.

Để kiểm tra đơn vị kho lưu trữ, tôi viết một bài kiểm tra tích hợp để đánh vào cơ sở dữ liệu. Để kiểm tra đơn vị quy tắc kinh doanh, tôi giả định kho lưu trữ, cung cấp dữ liệu phù hợp cho quy tắc kinh doanh và xác minh kết quả mong đợi của tôi được trả về.

Những gì tôi muốn làm: Để kiểm tra đơn vị UI, tôi giả định các quy tắc kinh doanh, thiết lập trường hợp khách hàng mong đợi của tôi, hiển thị chế độ xem và xác minh rằng chế độ xem có chứa các giá trị phù hợp cho trường hợp tôi đã chỉ định.

Những gì tôi đang mắc kẹt: Để kiểm tra đơn vị kho lưu trữ, tôi viết kiểm tra tích hợp, thiết lập thông tin đăng nhập phù hợp, tạo dữ liệu cần thiết trong cơ sở dữ liệu, mở trình duyệt, điều hướng đến khách hàng và xác minh trang kết quả có chứa trang phù hợp các giá trị cho ví dụ tôi đã chỉ định.

Tôi nhận ra rằng có sự chồng chéo giữa hai kịch bản được thảo luận ở trên, nhưng sự khác biệt chính là thời gian và nỗ lực cần thiết để thiết lập và thực hiện các thử nghiệm.

Nếu tôi (hoặc nhà phát triển khác) xóa trường địa chỉ khỏi chế độ xem, tôi không muốn chờ kiểm tra tích hợp để khám phá điều này. Tôi muốn được phát hiện và gắn cờ trong một bài kiểm tra đơn vị được nhiều lần mỗi ngày.

Tôi có cảm giác rằng tôi chỉ không nắm bắt được một số khái niệm quan trọng. Ai đó có thể giải thích tại sao muốn phản hồi thử nghiệm ngay lập tức về tính hợp lệ của chế độ xem MVC là một điều xấu? (hoặc nếu không tệ, thì đó không phải là cách mong đợi để nhận phản hồi)

unit-testing asp.net-mvc

— Peter Bernier
nguồn

1

"To unit-test the repository, I write an integration test"Đợi ... cái gì? Đó không phải là một bài kiểm tra đơn vị của kho lưu trữ. Bạn đang tự động kiểm tra cho nó, nhưng mã được kiểm tra vẫn bao gồm DAL và cơ sở dữ liệu. Để kiểm tra đơn vị kho lưu trữ, bạn có cách ly nó giống như bạn có cho các quy tắc kinh doanh của mình.

— Người sử dụng Stuper

Kiểm tra đơn vị chế độ xem được hiển thị như mong đợi chỉ là kiểm tra đơn vị mà công cụ tạo khuôn mẫu của bạn hoạt động. Điều đó giống như kiểm tra đơn vị C đã biên dịch của bạn chứa một số đoạn mã máy nhất định, đơn vị của bạn kiểm tra trình biên dịch không phải mã của bạn.

— Raynos

2

@Raynos Trân trọng, tôi sẽ không đồng ý. Nếu tôi (hoặc nhà phát triển khác) kết nối nhầm giao diện người dùng để kết xuất một thuộc tính dữ liệu trong trường UI cho người khác (Ví dụ: 'Tên' trong 'Trường tên cuối', điều đó không liên quan gì đến công cụ tạo khuôn mẫu, cũng không liên quan nó là vấn đề của DAL hay BR .. rõ ràng đây là một vấn đề chỉ được phơi bày trên màn hình.

— Peter Bernier

1

@PeterBernier bạn có một điểm tốt, nhưng tôi thấy khó xác định ranh giới giữa "kiểm tra xem trình biên dịch có hoạt động không" và "kiểm tra xem mã của tôi có hoạt động không". Chưa kể các bài kiểm tra cho UI được kết hợp chặt chẽ với UI. Mọi thay đổi đối với UI đều khiến các bài kiểm tra thất bại. Bạn thực sự không thể thực hiện bất kỳ loại tái cấu trúc UI nào mà không khiến thử nghiệm thất bại.

— Raynos

9

Kiểm tra giao diện người dùng đơn giản là đủ dễ dàng trong ASP.NET MVC. Về cơ bản, tất cả những gì bạn phải làm là khẳng định rằng HTML được trả về có chứa các yếu tố bạn cần. Mặc dù điều này đảm bảo rằng trang HTML được cấu trúc theo cách bạn mong đợi, nhưng nó không kiểm tra đầy đủ UI.

Kiểm tra giao diện người dùng web đúng cách yêu cầu một công cụ như Selenium sẽ sử dụng các trình duyệt trên máy của bạn và đảm bảo rằng JavaScript và HTML đang hoạt động đúng trong tất cả các trình duyệt. Selenium có một mô hình máy khách / máy chủ để bạn có thể có một bộ máy ảo với các máy khách Unix, Mac và Windows và bộ trình duyệt chung cho các môi trường đó.

Bây giờ, một ứng dụng MVC (mẫu, không phải khung) được thiết kế tốt sẽ đưa logic quan trọng vào các mô hình và bộ điều khiển. Nói tóm lại, chức năng của ứng dụng được kiểm tra khi bạn kiểm tra hai khía cạnh đó. Lượt xem có xu hướng chỉ có logic hiển thị và dễ dàng được kiểm tra bằng kiểm tra trực quan. Do quá trình xử lý mỏng trong chế độ xem và phần lớn ứng dụng được kiểm tra tốt, nhiều người không nghĩ rằng việc kiểm tra lớp khung nhìn vượt trội hơn lợi ích mà nó đạt được.

Điều đó nói rằng, MVC có một số phương tiện tốt để kiểm tra DOM được yêu cầu trả về. Điều đó làm giảm sự đau đớn một chút để kiểm tra lớp xem.

— Berin Loritsch
nguồn

1

"Về cơ bản, tất cả những gì bạn phải làm là khẳng định rằng HTML được trả về có chứa các yếu tố bạn cần." Đây chính xác là những gì tôi đang cố gắng thực hiện và hóa ra nó không tầm thường. Bạn có thể trỏ đến một liên kết nơi nó sẽ hoạt động với một hành động điều khiển cụ thể chứ không phải chỉ hiển thị một điều khiển không? (Tôi đã làm việc qua một vài bài viết, nhưng RenderPartial không hoàn thành những gì tôi muốn làm mà không cần chi phí đáng kể ..)

— Peter Bernier

Bạn sẽ muốn kiểm tra mvccontrib.codeplex.com (MVC Contrib). Điều này cung cấp trợ giúp không được tích hợp vào ngôn ngữ cốt lõi và được đề xuất trong cuốn sách "Test-Drive ASP.NET MVC" (lập trình viên thực dụng). Mặc dù vậy, tôi vẫn nghĩ Selenium phù hợp hơn với thử nghiệm View.

— Berin Loritsch

TestHelper (MVC Contrib): mvccontrib.codeplex.com/ Từ

— Berin Loritsch

Selenium (trong trường hợp của tôi Selenium RC) là những gì tôi sẽ sử dụng cho các bài kiểm tra tích hợp của mình. Những gì tôi muốn là cho một thất bại xảy ra trước thời điểm đó.

— Peter Bernier

2

@Peter: Nhận xét của bạn về những nỗ lực của bạn là "không tầm thường" chính xác là lý do khiến các quan điểm kiểm tra đơn vị được tán thành. Do đó, một chiến lược điển hình là làm cho các khung nhìn càng mỏng càng tốt (nghĩa là không chứa logic kinh doanh), để hầu hết các thử nghiệm đơn vị có thể diễn ra ở một nơi khác (nói chung là trong ViewModel). Bản thân các khung nhìn có thể được xác minh bằng kiểm tra trực quan hoặc bằng công cụ kiểm tra giao diện người dùng như Selenium.

— Robert Harvey

7

Tôi sẽ không nói nó nhăn mặt. Thay vào đó, tình cảm đó là kết quả của thực tế là các khung nhìn MVC thử nghiệm đơn vị (ít nhất là giống aspx) khá khó khăn vì các khung nhìn aspx có quá nhiều sự phụ thuộc vào WebForms, bản thân chúng không thể kiểm chứng được. Vì vậy, tranh luận cho rằng nó không đáng để nỗ lực vì các quan điểm có xu hướng không quá phức tạp.

Tất nhiên, quan điểm có thể trở nên khá phức tạp vì vậy đó là lựa chọn của bạn.

— marcind
nguồn

3

Các khung nhìn ASP.NET MVC không bị ràng buộc với Webforms, theo như tôi biết. Không phải là một trong những điểm lớn của ASP.NET MVC mà không phải là Webforms sao?

— Adam Lear

Quan điểm của tôi là cần nhiều nỗ lực của con người hơn để viết các bài kiểm tra tích hợp để bao quát UI, hơn là viết 'bài kiểm tra đơn vị' thực sự để bao quát các quan điểm. Đó là lý do tại sao tôi đang cố gắng để hiểu một số kháng cự dường như ở ngoài đó đối với việc viết các bài kiểm tra đơn vị cho các quan điểm.

— Peter Bernier

Lượt xem @Anna Aspx được xây dựng dựa trên WebForms. Chúng xuất phát từ System.Web.UI.WebControls.Pagelớp, sử dụng các <asp:ContentPlaceholder>điều khiển, v.v ... Cách MVC thực thi chúng tránh được rất nhiều đường dẫn thực thi Trang thường được liên kết với WebForms nhưng nó vẫn sử dụng rất nhiều công cụ WebForms dưới vỏ bọc.

— hôn

Nếu bạn sử dụng một công cụ xem khác (như dao cạo râu), bạn sẽ có thể di chuyển ra xa khỏi công cụ Webforms.

— Người đàn ông Muffin

6

Tôi không chắc chắn rằng nó đang nhăn mặt. Khả năng kiểm tra là một trong những lợi ích chính của việc sử dụng ASP.NET MVC. Kiểm tra blog của Steve Sanderson để biết thêm thông tin về điều này.

Ông cũng đã viết cuốn sách ASP.MVC (IMO) tốt nhất hiện có. Anh ta không chỉ dạy MVC, mà còn vượt lên trên để dạy các thực tiễn tốt nhất xung quanh nó, bao gồm cả các thực hành thử nghiệm.

Tôi nghĩ rằng tôi cần phải làm rõ một chút về các chế độ xem thử nghiệm đơn vị - bạn có thể xây dựng các thử nghiệm đơn vị xung quanh kết quả được trả về từ bộ điều khiển (ActionResult, v.v.). Bạn vẫn sẽ cần thực hiện các thử nghiệm khác cho tương tác UI và UI thực tế.

— Mark Freedman
nguồn

"Bạn vẫn sẽ cần thực hiện các thử nghiệm khác cho tương tác UI và UI thực tế." Đó chính xác là quan điểm của tôi về câu hỏi .. tại sao các bài kiểm tra UI đột nhiên trở thành một phần của 'thử nghiệm khác' (nghĩa là thử nghiệm tích hợp). Tôi đã thấy rất nhiều nội dung của Steve Sanderson và đó là những gì khiến tôi bắt đầu con đường này, về cơ bản là cố gắng sao chép những gì anh ta đang làm với dự án 'MvcFakes' của anh ta và gặp vấn đề với mã của anh ta được viết cho các bản phát hành MVC cũ hơn. .

— Peter Bernier

1

Bạn có thể tìm hiểu cách kiểm tra Chế độ xem được trả về bằng hành động của bộ điều khiển, cách kiểm tra Xem dữ liệu được trả về bởi hành động của bộ điều khiển và cách kiểm tra xem một hành động của bộ điều khiển có chuyển hướng bạn đến hành động của bộ điều khiển thứ hai hay không bằng cách kiểm tra URL sau, mô tả trong bài viết ngắn gọn này về Kiểm tra dữ liệu xem trong MVC .

— Jaypee
nguồn