2009-11-06 26 views
16

Tôi có một lớp được gọi là "Phiên" để hiển thị một số phương thức công khai. Tôi muốn Unit Test này, tuy nhiên trong sản xuất tôi cần phải kiểm soát instantiation của các đối tượng "Session", do đó, ủy quyền xây dựng đến một lớp SessionManager và đã làm cho constructor của Session bên trong. Tôi muốn thử nghiệm lớp Session một cách riêng biệt với SessionManager để tạo ra nó để chứng minh rằng các giao diện công khai được tiếp xúc bởi Session làm việc như mong đợi - nhưng không thể khởi tạo một Session từ một bài kiểm tra mà không sử dụng một SessionManager làm cho các bài kiểm tra của tôi phức tạp hơn/ít hữu ích hơn mức cần thiết.Đơn vị Thử nghiệm một lớp học với một hàm tạo nội bộ

Cách tốt nhất để giải quyết vấn đề này là gì?

Chúc mừng,

Lenny.

+0

Plese rõ ràng lên: là nó được bảo vệ ___or___ một nhà xây dựng nội bộ? –

Trả lời

42

Không có gì ngăn cản bạn từ internals kiểm tra Đơn giản chỉ cần làm cho bên trong của mã của bạn có thể nhìn thấy các bộ kiểm tra, bằng cách sử dụng các thuộc tính InternalsVisibleTo:.. trong AssemblyInfo, thêm

[assembly:InternalsVisibleTo("TestSuiteAssembly")] 
+0

Điều này có vẻ là cách dễ nhất để làm điều đó, vì vậy tôi nghĩ rằng tôi sẽ chạy với điều này. Cảm ơn. –

+1

Câu trả lời là không thực sự hoàn thành - các hội đồng phải được ký kết để làm cho nó hoạt động. – Santhos

+0

@Santhos không thực sự ... –

2

Bạn chỉ có thể làm cho lớp thử nghiệm đơn vị của bạn kế thừa từ Phiên (giả sử khung kiểm tra của bạn không yêu cầu bạn kế thừa từ một lớp cụ thể). Ví dụ, với NUnit:

[TestFixture] 
public class SessionTest : Session 
{ 
    public SessionTest() 
     : base() // call protected constructor 
    { 
    } 

    [Test] 
    public void TestSomething() 
    { 
    } 

} 
+1

OP cho biết ctor là nội bộ, không được bảo vệ. –

+0

@Rex - tiêu đề của câu hỏi được bảo vệ, trong khi câu hỏi tự nói nội bộ. –

1

Bạn muốn sử dụng một sản phẩm như TypeMock, mà sẽ cho phép bạn tạo ra chế giễu (giả) trường hợp của các lớp học, như thế này:

var myInstance = Isolate.Fake.Instance<Session>(); 
// mock behavior here 
// do assertions here 

Bạn có thể tạo các trường hợp các lớp trừu tượng với TypeMock, cho bản ghi.

+3

chế giễu cùng một lớp mà bạn muốn thử nghiệm không có ý nghĩa với tôi mặc dù ... bạn sẽ không thử nghiệm mô hình và không phải là lớp học sau đó? – Svish

+0

@ Tuyệt vời, bạn chính xác rằng hành vi giả mạo không hữu ích, nhưng nó cũng có thể tạo ra cá thể thực và giải quyết vấn đề trợ năng: Isolate.Fake.Instance (Members.CallOriginal). Bằng cách này bạn có một thể hiện thực sự của lớp với constructor của ai là không thể tiếp cận. Tuyên bố từ chối trách nhiệm - Tôi làm việc tại Typemock. – Elisha

2

Ngoài ra, như một giải pháp thay thế, bạn chỉ có thể tạo một TestSession kế thừa từ Phiên và hiển thị một hàm tạo công khai. Bên trong bài kiểm tra đơn vị của bạn, bạn sử dụng TestSession về cơ bản giống như đối tượng Session ban đầu.

public class TestSession : Session 
{ 

    public TestSession() : base() 
    { 

    } 

} 
1

Tôi sẽ đặt câu hỏi về giá trị của việc tạo hàm tạo lớp phiên.

Nói chung điều này ngụ ý bạn đang cố gắng ngăn các nhà phát triển khác sử dụng lớp học của bạn. Có lẽ sẽ tốt hơn khi giao tiếp cách phần ứng dụng cụ thể này hoạt động và tại sao bạn chỉ muốn truy cập phiên từ trình quản lý phiên?

+0

Tôi đã nhìn thấy nó được thực hiện rất nhiều với một mô hình nhà máy, nơi bạn có thể muốn thực thi rằng lớp chỉ được tạo ra hoặc bị hủy ở một nơi, nhưng những người khác được phép tham chiếu và sử dụng nó. –

+0

Tôi đã nhìn thấy nó rất nhiều :) Tôi chỉ không thấy làm thế nào nó thêm bất kỳ giá trị. Nó chỉ gây ra vấn đề khi bạn muốn mở rộng hoặc kiểm tra - giống như Leonard đang trải qua bây giờ. MS là một trong những kẻ phạm tội tồi tệ nhất trong lĩnh vực này, có rất nhiều lớp nội bộ hữu ích khi sử dụng đôi khi, nhưng chúng tôi không thể truy cập chúng! Bực bội! –

+5

Là người từng là người tiêu dùng API, và rất thất vọng như bạn tự hỏi tại sao MS tạo ra rất nhiều thứ nội bộ, được bảo vệ, v.v. Bây giờ tôi chủ yếu phát triển API và công cụ của tôi được các nhà phát triển khác tiêu thụ. Tôi dành nhiều thời gian để dọn dẹp đống lộn xộn của người khác bởi vì họ gặp rắc rối khi sử dụng những thứ tôi nên làm bên trong. Đôi khi nó chỉ là không thực tế để mong đợi để có thể giao tiếp "đúng" sử dụng của tất cả các đoạn mã chúng tôi viết. –

0

Nếu bạn có thể để lại với hàm dựng "bên trong được bảo vệ", thì giả định rằng các thử nghiệm của bạn nằm trong các assembly khác nhau, bạn có thể thêm thuộc tính InternalsVisibleTo vào "assembly được thử nghiệm" của bạn. Điều này sẽ cho phép kiểm tra để xem các thành viên nội bộ của to-be-kiểm tra-lắp ráp".

Cập nhật Đối với một số lý do tôi đọc mà constructor của bạn được bảo vệ. Nó đã được nội bộ, do đó bạn đang ở trong một vị trí tốt để sử dụng thuộc tính mà

Các vấn đề liên quan