Thực tiễn tốt nhất để tích hợp TDD với phát triển ứng dụng web?

Question

Kiểm tra đơn vị và ứng dụng web ASP.NET là một điểm mơ hồ trong nhóm của tôi. Thường xuyên hơn không, thực hành thử nghiệm tốt rơi qua các vết nứt và các ứng dụng web sẽ kết thúc trong vài năm mà không có thử nghiệm nào.

Nguyên nhân gây ra điểm đau này thường xoay quanh sự phức tạp của việc viết tự động hóa giữa quá trình phát triển UI.

Bạn hoặc tổ chức của bạn tích hợp các phương pháp TDD tốt nhất với phát triển ứng dụng web như thế nào?

Answer 1

Kiểm tra đơn vị sẽ đạt được nếu bạn tách riêng các lớp của bạn một cách thích hợp . Như Rob Cooper ngụ ý, không đặt bất kỳ logic nào trong WebForm của bạn ngoài logic để quản lý bản trình bày của bạn. Tất cả các công cụ logic và các lớp kiên trì khác nên được giữ trong các lớp riêng biệt và sau đó bạn có thể kiểm tra từng cá nhân.

Để kiểm tra GUI, một số người thích selenium. Những người khác phàn nàn rằng đó là một nỗi đau để thiết lập.

Answer 2

Tôi loại bỏ ứng dụng và kiểm tra đơn vị ít nhất từ ​​trình dẫn/bộ điều khiển (tùy theo tùy chọn nào của bạn, mvc/mvp) vào lớp dữ liệu. Bằng cách đó tôi có phạm vi kiểm tra tốt trên hầu hết các mã được viết.

Tôi đã xem FitNesse, Watin và Selenium là các tùy chọn để tự động kiểm tra giao diện người dùng nhưng tôi chưa sử dụng chúng trên bất kỳ dự án nào, vì vậy chúng tôi tuân thủ thử nghiệm của con người. FitNesse là người tôi đang nghiêng về phía trước nhưng tôi không thể giới thiệu điều này cũng như giới thiệu TDD (điều đó làm tôi xấu đi? Tôi hy vọng là không!).

Answer 3

Đây là một câu hỏi hay, một trong đó tôi sẽ được đăng ký quá :)

Tôi vẫn còn tương đối mới để dev web, và tôi cũng đang xem xét rất nhiều mã mà phần lớn là chưa được kiểm tra.

Đối với tôi, tôi giữ giao diện người dùng càng nhẹ càng tốt (thường chỉ là một vài dòng mã) và kiểm tra mọi thứ khác. Ít nhất thì tôi có thể tự tin rằng mọi thứ làm cho giao diện người dùng đều chính xác như nó có thể.

Hoàn hảo? Có lẽ không, nhưng ít nhất nó vẫn còn khá tự động và mã lõi (nơi mà hầu hết "ma thuật" xảy ra) vẫn có độ phủ khá tốt ..

Answer 4

Một thực tế phổ biến là di chuyển tất cả các mã bạn có thể ra khỏi codebehind và vào một đối tượng bạn có thể thử nghiệm trong sự cô lập. Mã như vậy thường sẽ theo các mẫu thiết kế MVP hoặc MVC. Nếu bạn tìm kiếm trên "Rhino Igloo", có thể bạn sẽ tìm thấy liên kết đến kho lưu trữ Subversion của nó. Mã đó đáng để nghiên cứu, vì nó chứng tỏ một trong những triển khai MVP tốt nhất trên các Biểu mẫu Web mà tôi đã thấy.

codebehind của bạn sẽ, khi sau mô hình này, làm hai việc:

1. Transit mọi hành động sử dụng để trình bày.
2. Hiển thị dữ liệu do người trình bày cung cấp.

Kiểm tra đơn vị người trình bày không đáng kể.

Cập nhật: Rhino Igloo có thể được tìm thấy ở đây: https://svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-igloo/

Answer 5

Đã có cố gắng vào việc của Microsoft Tự động hóa giao diện người dùng miễn phí (bao gồm trong .NET Framework 3.0) để làm việc với các ứng dụng web (ASP.NET). Một công ty Đức tên là Artiso đã viết một bài viết blog giải thích làm thế nào để đạt được điều đó (link).

Tuy nhiên, blogpost của họ cũng liên kết một MSDN Webcasts giải thích Khung Tự động hóa Giao diện người dùng với biểu mẫu thắng và sau khi tôi xem xét điều này, tôi nhận thấy bạn cần AutomationId để tham chiếu đến các điều khiển tôn trọng. Tuy nhiên, trong các ứng dụng web, các điều khiển không có AutomationId.

Tôi đã hỏi Thomas Schissler (Artiso) về điều này và ông giải thích rằng đây là một nhược điểm lớn trên InternetExplorer. Ông tham khảo một công nghệ cũ của Microsoft (MSAA) và hy vọng bản thân rằng IE8 sẽ làm điều này tốt hơn.

Tuy nhiên, tôi cũng đang thử Watin và dường như nó hoạt động khá tốt. Tôi thậm chí thích Wax, cho phép thực hiện testcases đơn giản thông qua các bảng tính Microsoft Excel.

Answer 6

Ivonna đơn vị có thể kiểm tra chế độ xem của bạn. Tôi vẫn khuyên bạn nên di chuyển hầu hết mã này sang các phần khác. Tuy nhiên, một số mã chỉ thuộc về ở đó, như tham chiếu đến điều khiển hoặc kiểm soát trình xử lý sự kiện.

Answer 7

Tôi thường tránh thử nghiệm liên quan đến việc dựa vào các yếu tố giao diện người dùng. Tôi ủng hộ thử nghiệm tích hợp, kiểm tra mọi thứ từ lớp cơ sở dữ liệu của bạn lên lớp xem (nhưng không phải là bố cục thực tế).

Hãy thử bắt đầu một bộ kiểm tra trước khi viết một dòng mã thực trong một dự án mới, vì khó viết các bài kiểm tra sau này.

Chọn cẩn thận những gì bạn kiểm tra - đừng lo lắng viết các bài kiểm tra cho mọi thứ. Đôi khi nó là một nhiệm vụ nhàm chán, do đó, không làm cho nó khó khăn hơn. Nếu bạn viết quá nhiều bài kiểm tra, bạn có nguy cơ từ bỏ nhiệm vụ đó theo trọng lượng bảo trì tốn thời gian.

Cố gắng gộp nhiều chức năng nhất có thể vào một thử nghiệm. Bằng cách đó, nếu có điều gì sai, các lỗi sẽ được truyền đi. Ví dụ, nếu bạn có một lớp sinh ra digest - kiểm tra đầu ra thực tế, không phải mọi hàm trợ giúp đơn lẻ.

Đừng tin tưởng chính mình. Giả sử rằng bạn sẽ luôn phạm sai lầm, và vì vậy bạn viết các bài kiểm tra để làm cho cuộc sống của bạn dễ dàng hơn, không khó hơn.

Nếu bạn không cảm thấy thoải mái khi viết bài kiểm tra, có thể bạn đang làm sai;)