NMock2.0 - làm thế nào để stub một cuộc gọi không giao diện?

Question

Tôi có một API lớp có phạm vi mã đầy đủ và sử dụng DI để loại bỏ tất cả logic trong hàm lớp chính (Job.Run) thực hiện tất cả công việc.

Tôi đã tìm thấy lỗi trong quá trình sản xuất mà chúng tôi không thực hiện một số xác thực trên một trong các trường nhập dữ liệu. Vì vậy, tôi đã thêm một hàm sơ khai được gọi là ValidateFoo() ... Đã viết một bài kiểm tra đơn vị với hàm này để mong đợi một JobFailedException, chạy thử nghiệm - nó không thành công rõ ràng vì hàm đó rỗng. Tôi đã thêm logic xác thực và giờ thử nghiệm đã trôi qua.

Tuyệt vời, bây giờ chúng tôi biết xác thực hoạt động. Vấn đề là - làm thế nào để tôi viết các bài kiểm tra để đảm bảo rằng ValidateFoo() thực sự được gọi là bên trong Job.Run()? ValidateFoo() là một phương thức riêng của lớp Job - vì vậy nó không phải là một giao diện ...

Có cách nào để thực hiện điều này với NMock2.0 không? Tôi biết TypeMock hỗ trợ hàng giả của các loại giao diện không. Nhưng thay đổi lib giả lập ngay bây giờ không phải là một lựa chọn. Tại thời điểm này nếu NMock không thể hỗ trợ nó, tôi sẽ chỉ cần thêm lệnh ValidateFoo() vào phương thức Run() và kiểm tra mọi thứ theo cách thủ công - mà rõ ràng là tôi không thích xem xét phương thức Job.Run() của tôi Phạm vi phủ sóng 100% ngay bây giờ. Bất kỳ lời khuyên nào? Cảm ơn rất nhiều nó được đánh giá cao.

CHỈNH SỬA: tùy chọn khác mà tôi có trong đầu là tạo thử nghiệm tích hợp cho chức năng Job.Run của tôi (tiêm vào thực thi đúng đối tượng hỗn hợp thay vì mocks). Tôi sẽ cung cấp cho nó một giá trị đầu vào xấu cho lĩnh vực đó và sau đó xác nhận rằng công việc thất bại. Điều này hoạt động và bao gồm thử nghiệm của tôi - nhưng nó không thực sự là một bài kiểm tra đơn vị mà là kiểm thử tích hợp để kiểm tra một đơn vị chức năng .... h2 ..

EDIT2: Có cách nào để làm tih không? Bất cứ ai có ý tưởng? Có lẽ TypeMock - hoặc một thiết kế tốt hơn?

Answer 1

The current version of NMock2 có thể thử các loại bê tông (tôi không nhớ chính xác phiên bản nào họ đã thêm vào điều này, nhưng chúng tôi đang sử dụng phiên bản 2.1) bằng cách sử dụng cú pháp chủ yếu là quen thuộc:

Job job = mockery.NewMock<Job>(MockStyle.Transparent); 
Stub.On(job).Method("ValidateFoo").Will(Return.Value(true)); 

MockStyle.Transparent quy định rằng bất cứ điều gì bạn không stub hoặc mong đợi nên được xử lý bởi việc thực hiện cơ bản - vì vậy bạn có thể stub và đặt kỳ vọng cho các phương pháp trên một thể hiện bạn đang thử nghiệm.

Tuy nhiên, bạn chỉ có thể khai thác và đặt kỳ vọng về phương pháp công khai (và thuộc tính), cũng phải là ảo hoặc trừu tượng. Vì vậy, để tránh dựa vào thử nghiệm tích hợp, bạn có hai tùy chọn:

• Đặt Job.ValidateFoo() công khai và ảo.
• Trích xuất logic xác thực vào một lớp mới và đưa một cá thể vào Job.

Answer 2

Vì tất cả cá nhân đều được gọi bằng phương thức công cộng (trừ khi dựa vào thực thi thời gian chạy phản chiếu), thì các tư nhân đó đang được thực thi bằng phương pháp công khai. Những phương thức riêng đó đang gây ra những thay đổi đối với đối tượng ngoài việc thực thi mã, chẳng hạn như thiết lập các trường lớp hoặc gọi vào các đối tượng khác. Tôi muốn tìm một cách để có được những "kết quả" của việc gọi phương thức riêng. (Hoặc chế giễu những thứ không nên được thực hiện theo phương pháp riêng.)

Tôi không thể thấy lớp đang được kiểm tra.Một vấn đề khác có thể khiến bạn muốn truy cập vào các phương thức riêng tư là nó là một lớp siêu lớn với một tải trọng của tính năng riêng tư. Những lớp này có thể cần phải được chia nhỏ thành các lớp học nhỏ hơn, và một số trong số những cá nhân đó có thể trở thành công chúng đơn giản hơn.