|Home||Back to Index|
(Previous article: Mocks: The Next Generation)
Ayende released the new version of Rhino Mocks. I’m still not satisfied with its support for stubbing properties (read-only properties must be handled differently from read-write properties). See this discussion on the Rhino.Mocks group for details. I also don’t like the requirement of BackToRecord/Replay calls to change a previous expectation.
Both of these concerns are addressed by Moq. I had felt that Moq’s ExpectGet syntax was wordy for properties, but now feel that the price for Rhino’s PropertyBehavior (different syntax for read-write properties) is too high. I’m also coming to appreciate the power of Moq’s It.Is syntax (another former complaint).
One downside to Moq is that it currently does not support out or ref properties. Apparently this has been added to the trunk and will be in the next release.
I went back and wrote more learning tests against Moq, handling the same cases as my Rhino Mocks v3.5 tests. These went well, so I tried porting some real-world tests to it. I ran into a roadblock here; see my post on the Moq Discussions group for details. This may be more of a code smell in my tests than a major limitation in Moq, so please don’t take this as a critique of the library.
I tend to get frustrated when using Rhino Mocks, and so far Moq has (mostly) worked as I expected. I think Ayende’s last comment on the aforementioned thread is particularly interesting:
You can use a mock instead of a stub, and only use Stub().
To me, this lends credence to Daniel Cazzulino’s comments that understanding the difference between stubs and mocks is largely irrelevant.
Update - October 6, 2008
See Switching to Moq.