Các yếu tố chính trong việc lựa chọn một Mocking Framework là gì?

Tôi đang tìm cách để bắt đầu với các đối tượng trong bài kiểm tra đơn vị của tôi. Có vẻ như có rất nhiều khung mô phỏng tốt ngoài kia.

1. Các khung khác nhau có đối tượng mục tiêu khác nhau?
2. Những yếu tố nào tôi nên xem xét khi chọn khung nào phù hợp với tình huống của tôi?

Các khung khác nhau có đối tượng mục tiêu khác nhau?

Đúng. Một số khung như Microsoft Moles , TypeMock Isolator và JustMock , cho phép bạn có thể chế giễu bất cứ thứ gì. Các công cụ giả định này thường tốt hơn cho các nhà phát triển muốn sử dụng chúng trên mã kế thừa hiện có vì không thể tái cấu trúc như vậy thành một thiết kế dễ kiểm tra hơn. *

Theo truyền thống, kiểu dáng thể kiểm chứng có nghĩa là codebase cần phải sử dụng tự do của các giao diện, lớp trừu tượng, phương pháp ảo, lớp niêm phong, vv Vì vậy, mocking frameworks truyền thống như Moq và RhinoMocks làm việc tốt với mã được phát triển sử dụng Test Driven Development, Dependency Injection, và khái niệm khác như vậy. Nhân tiện, tôi thực sự khuyên bạn nên sử dụng Dependency Injection vì bạn đạt được nhiều hơn là chỉ có thể kiểm tra mã, nhưng cũng có thể duy trì nhiều mã hơn.

Những yếu tố nào tôi nên xem xét khi chọn khung nào phù hợp với tình huống của tôi?

• Hoạt động phát triển. Các công cụ như Moq và RhinoMocks rất tích cực và phổ biến và do đó được cập nhật.
• Mã nguồn mở Vs. Thương mại . Hãy xem xét những ưu và nhược điểm điển hình cho việc so sánh này. Chi phí, hỗ trợ, v.v ...
• Trưởng thành. Làm thế nào mới là công cụ. Đây có phải là bản beta (như Microsoft Moles) hay đã có một vài bản phát hành ổn định? Ví dụ: tôi thích Moles cho mã kế thừa, nhưng có một số lỗi cần xử lý trong đó và sẽ phải chờ đợi trước khi chúng được xử lý (bản phát hành tiếp theo vào tháng 11 năm 2011).
• Tài liệu. Có một số sách và blog bao gồm kiểm tra đơn vị, chế nhạo, tự động chế tạo, v.v. Ngoài ra, tài liệu của công cụ này tốt đến mức nào?
• Cú pháp . Mỗi công cụ có cách nói riêng của nó. Xem cái nào phù hợp hơn với bạn.
• Tốc độ . Các công cụ sử dụng hồ sơ CLR (TypeMock, Moles, JustMock), có thể chậm hơn nhiều so với các công cụ truyền thống (Moq, RhinoMocks). Hình phạt tốc độ này có thể là một vấn đề vì bạn có nhiều bài kiểm tra đơn vị. Nguyên tắc chung là nếu một bài kiểm tra mất nhiều thời gian hơn 1/10 giây thì quá chậm.
• Hỗ trợ cộng đồng . Có phải các nhà phát triển khác đang viết các công cụ khác mở rộng (hoặc hoạt động để khen ngợi) cho công cụ chế nhạo? Có một dự án Moq.Contrib bổ sung khả năng Auto-mocking cho Moq (giúp tăng tốc thời gian viết bài kiểm tra). Tốt hơn nữa, có AutoFixture , AutoFixture.AutoMoq, AutoFixture.AutoRhinoMocks, cũng cho phép Auto-mocking, cộng với việc tạo biến ẩn danh.

^{* Xem Hoạt động hiệu quả với Mã kế thừa , để biết cách làm thế nào để từ từ mã lại mà không cần kiểm tra thành mã có thể được sử dụng với các công cụ kiểm tra (và chế nhạo) truyền thống.}

Các Moq hướng dẫn có một phần trên nền, triết học, và tranh cãi ngay từ đầu mà thảo luận này liên quan đến một vài công cụ cụ thể: TypeMock Isolator, RhinoMocks, và Moq. Nó được viết để giải thích Moq, do đó, tự nhiên có một chút sai lệch, nhưng tôi thấy nó khá hữu ích cho tôi khi cố gắng hiểu một số khác biệt trong các khung mô phỏng.

Tôi thấy các phản hồi cho chủ đề SO này trên C # Mocking Framework cũng hữu ích. Hầu hết chỉ đề cập đến một Mocking Framework mà người dùng thực sự thấy hữu ích, nhưng có một phản hồi từ HaraldV về cách thảo luận về các giả lập dựa trên proxy và các giả lập dựa trên trình biên dịch.

Tôi cũng có thể tìm thấy một biểu đồ so sánh trực tuyến. Lưu ý rằng đó là từ năm 2009, vì vậy tôi không chắc nó đã được cập nhật; có ít nhất một bình luận nói rằng thông tin về TypeMock và các cuộc gọi lại đã lỗi thời, nhưng biểu đồ có thể tốt để đưa ra các vấn đề cần xem xét ngay cả khi bạn sẽ cần phải làm việc để xem trạng thái hiện tại là gì: RhinoMocks, Moq, NMock, và biểu đồ so sánh TypeMock

Có một dự án về Google Code với các trường hợp thử nghiệm trong nhiều khung mô phỏng để so sánh mã dễ dàng: so sánh khung mô phỏng

1. Dễ sử dụng. Một số khung có thành ngữ nâng cao hơn về cách sử dụng. Ví dụ, Moq cho phép sử dụng lambdas để mã hóa kỳ vọng. Một số thư viện cũ không hỗ trợ này.
2. Tốc độ. Mỗi bài kiểm tra đơn vị phải nhanh để toàn bộ thư viện của bạn không mất nhiều giờ để chạy. Một số khung mô phỏng có các giả lập được tạo tĩnh, nhanh. Các khung công tác khác tự động tạo mã khi chạy, tốc độ chậm hơn.
3. Ủng hộ. Bạn muốn một khung được hỗ trợ tích cực với các bản sửa lỗi và được cập nhật để hỗ trợ các phiên bản .NET mới, khi chúng được phát hành.
4. Quyền lực. Hầu hết các khung mô phỏng mà tôi đã nghiên cứu gần như giống nhau về sức mạnh. Có một ngoại lệ đáng chú ý. Microsoft Moles cho phép chế nhạo "các phương thức không ảo / tĩnh trong các loại kín". Đây là điều mà không có khung mô phỏng nào khác hỗ trợ, theo hiểu biết của tôi.

Trong nhóm của tôi, chúng tôi đã chọn Microsoft Moles . Nó chiến thắng đáng kể ở # 2, # 3 và # 4, mặc dù nó ít thành ngữ hơn so với hầu hết các lựa chọn thay thế và nằm ở cấp thấp trên # 1.