Tổ chức dự án thử nghiệm đơn vị .NET

Question

Bạn sẽ nói gì là cách tốt nhất để quản lý các thử nghiệm đơn vị trong một ứng dụng .net lớn? Có nên thêm dự án thử nghiệm cho từng dự án riêng biệt trong giải pháp hoặc một dự án thử nghiệm lớn cho tất cả các thử nghiệm trong phần còn lại của dự án không?

Ví dụ nếu có 10 dự án trong một giải pháp, tốt hơn là có thêm 10 dự án thử nghiệm hoặc một dự án thử nghiệm lớn sẽ đủ cho toàn bộ giải pháp?

Tôi biết có một số lợi ích được cung cấp bởi các hội đồng kiểm tra mô-đun, nhưng những điều khá giống nhau có thể đạt được bằng cách sử dụng các loại kiểm tra. Việc biên dịch mất nhiều thời gian hơn với nhiều dự án, nhưng bạn có thể loại trừ các dự án mà bạn không cần tại thời điểm đó, trong khi nếu bạn có một dự án duy nhất, bạn không thể làm điều đó, nhưng quá trình biên dịch mất ít thời gian hơn một chút.

Hãy phác thảo các ưu điểm/nhược điểm cho từng lựa chọn trong câu trả lời của bạn.

Answer 1

Phil Haack đã viết một bài viết hay về việc cấu trúc các bài kiểm tra đơn vị. Điều này đã trở thành thực hành tốt nhất của cá nhân tôi khi viết bài kiểm tra đơn vị. Đây là liên kết đến bài viết của mình http://haacked.com/archive/2012/01/02/structuring-unit-tests.aspx

Đối với câu hỏi của bạn, tôi sẽ luôn tạo một dự án riêng biệt để kiểm tra đơn vị và đặt tên nó với .UnitTests nối thêm (Tôi làm điều này để phân biệt giữa các bài kiểm tra đơn vị và tích hợp). Ví dụ, nếu dự án chính của tôi là Sample.WebUI, thử nghiệm sẽ là Sample.WebUI.UnitTests.

Đúng là các bài kiểm tra đơn vị bổ sung thêm thời gian để biên dịch, nhưng tôi cho rằng một vấn đề nhỏ. Tôi đang làm việc trên một giải pháp với 17 dự án (không bao gồm kiểm tra đơn vị) và mất khoảng 50-60 giây để biên dịch mọi thứ.Nó chỉ là khoảng thời gian đủ để rời mắt khỏi màn hình và nhìn vào một cái gì đó khác để thay đổi :-)

Về các danh mục, nếu bạn có một số bản dựng hàng ngày yêu cầu kiểm tra để hoàn thành nhanh chóng, sau đó sử dụng chúng và phân biệt chúng từ những thử nghiệm mất nhiều thời gian hơn để hoàn thành (như kiểm tra tích hợp). Ngoài ra, nếu bạn đang sử dụng TFS, việc sử dụng các danh mục có thể giúp tự động hóa và kiểm tra các checkins của bạn.

Answer 2

nhìn vào câu hỏi này: "Best Practice: Organize Unit Tests"

mặc dù kích thước giải pháp trong câu hỏi là khác nhau, các văn bản hướng dẫn vẫn còn hợp lệ.

Answer 3

Cá nhân tôi thích có một dự án thử nghiệm chuyên dụng cho mỗi dự án thực. Khi nói đến việc xây dựng một tính năng/mô-đun/dự án mới, tôi thấy nó tốt hơn nhiều để có thể nhanh chóng lọc ra bộ các dự án thử nghiệm không liên quan khác. Nó làm cho chu trình TDD nhanh hơn rất nhiều để có thể nhanh chóng chạy thử nghiệm cho dự án mới của tôi khi tôi phát triển nó.

Quan trọng hơn, nó giúp bạn duy trì một tổ chức tốt của các lớp thử nghiệm/mô phỏng khác nhau cho các đồ đạc của bạn khi cần mà không làm lộn xộn một đoạn mã không liên quan với nhau. Nó cũng giúp các nhà phát triển mới dễ dàng tìm thấy các bài kiểm tra phù hợp hơn. Cuối cùng, nó đảm bảo rằng các phụ thuộc của các thử nghiệm của bạn cho một dự án cụ thể không bao giờ vô tình phụ thuộc vào một dự án không liên quan khác.

Answer 4

Lựa chọn cá nhân của tôi là có một dự án thử nghiệm cho mỗi dự án chỉ với các bài kiểm tra đơn vị. Cấu trúc thư mục của thử nghiệm này chính xác giống như dự án đang được thử nghiệm. Bên cạnh đó, chúng tạo ra nhiều dự án thử nghiệm tích hợp khi cần thiết. Ưu điểm chính của phương pháp này là khi bạn muốn có 1 dự án và sử dụng nó trong một giải pháp khác, bạn luôn thực hiện dự án cùng nhau đảm bảo rằng khi bạn phải tạo cơ hội trong giải pháp mới thì chất lượng vẫn còn.

Cho đến bây giờ tôi không phát hiện ra bất kỳ sự khác biệt nào ngoài việc phải thay thế các tài liệu tham khảo nhiều hơn thì bạn phải làm khi sử dụng một thử nghiệm.