Ayende @ Rahien

Ayende Rahien commented on Planning for Rhino Mocks 4.0

Thu, 08 Oct 2009 05:50:51 GMT

gkdm, Send me a pach for hat

gkdm commented on Planning for Rhino Mocks 4.0

Thu, 08 Oct 2009 02:11:46 GMT

Ayenda my man, Questiion about the next version of RhinoMocks, Why not listen to the profiling API like TypeMock? seems to be a mighty mechanism..

Julius Ganns commented on Planning for Rhino Mocks 4.0

Thu, 17 Sep 2009 04:54:58 GMT

Hi Ayende, if you're looking for a fresh perspective (meaning, although I have developed some fairly complex apps and libs, I'm kind of new to Mocking and Stubbing), I would be interested in knowing how supporting your project would look like and how the API redesign is going to be planned, designed, constructed, tested and managed. Maybe you could create a new mailing list for newcomers that want to support the new 4.0 release. In that case, add my address to the list. Best, Julius

Colin Jack commented on Planning for Rhino Mocks 4.0

Tue, 15 Sep 2009 19:09:53 GMT

Sounds like a great idea.

Michael Braude commented on Planning for Rhino Mocks 4.0

Tue, 08 Sep 2009 17:37:52 GMT

I don't think you should remove the record / playback syntax at all. There's nothing wrong with having two systems if you need to: one that's built around AAA and another that validates order. It may be fashionable not to care about order validation, but at its heart, this is what I consider the core functionality of a mock API. It's critical that you allow users to be able to assert that one method on one object was invoked before another and that your infrastructure supports this. Whether they choose to write their tests in this style is up to them, but there are perfectly valid cases where asserting this behavior is important.

Ayende Rahien commented on Planning for Rhino Mocks 4.0

Sat, 05 Sep 2009 10:26:06 GMT

Judah, No, we intend to support side by side execution

Judah commented on Planning for Rhino Mocks 4.0

Fri, 04 Sep 2009 16:16:11 GMT

Wow, getting rid of the record/playback APIs, eh? We've got several thousand unit test in our production project right now that use this syntax: using(mocks.Record()) { ... } using(mocks.Playback()) { ... } Will we have to rewrite all of these to use the other syntax?

Ayende Rahien commented on Planning for Rhino Mocks 4.0

Fri, 04 Sep 2009 13:58:26 GMT

cowgaR, No, it will NOT be a 4.0 only version

Ayende Rahien commented on Planning for Rhino Mocks 4.0

Fri, 04 Sep 2009 13:57:38 GMT

Davy, I don't really like the linq syntax for Moq. As for the other stuff, please join the mailing list, we are discussing it over there right now.

David commented on Planning for Rhino Mocks 4.0

Fri, 04 Sep 2009 13:02:04 GMT

A LINQ provider to RM ala Moq ( [www.clariusconsulting.net/.../164978.aspx](http://www.clariusconsulting.net/blogs/kzu/archive/2009/08/13/164978.aspx)) would be nice. If RM is being put on an API diet, this is something that should probably be considered. My main gripe is the same as Isaac's: the inability to override stubs later on in the test, and that stubs automatically use PropertyBehavior (which forces me to use DynamicMock when I need to fake read only properties). I assume the flattening of all the different mock types will be addressing issues like this.

cowgaR commented on Planning for Rhino Mocks 4.0

Fri, 04 Sep 2009 12:24:07 GMT

ok so can you confirm it'll be C# 4.0 project only? thank you, sounds great, but .NET 4.0 is still far away (both in release and to production)

Arnis L. commented on Planning for Rhino Mocks 4.0

Fri, 04 Sep 2009 06:50:27 GMT

That's a right direction. In fact - i chose Moq just because of this - it's much more easier (it's API) for beginners.

Noam Gal commented on Planning for Rhino Mocks 4.0

Fri, 04 Sep 2009 06:01:29 GMT

Sounds great. As a beginner with Rhino and mocking in general, I struggled with all the different ways I can use it. Glad I managed to do AAA, as it will be the option that stays around.

Ray commented on Planning for Rhino Mocks 4.0

Fri, 04 Sep 2009 00:45:40 GMT

I completely support those plans. I've never fully grasped why anyone would prefer the playback stuff over AAA anyways, AAA is so much more intuitive.

Isaac commented on Planning for Rhino Mocks 4.0

Fri, 04 Sep 2009 00:27:02 GMT

The main thing you want to do is to simplify the API and make some improved docs for the common how-tos. The API is confusing to a newcomer because there are several ways of achieving the same thing - beginners want to know that there is one way of doing something and that what they are doing is right. Also - if you could make a way of "overriding" a stubbed method later on, that would be great. I often put a default stub in my TestInit method and then "override" it later on in specific tests, but it's difficult to do that with Rhino at the moment.

Dmitriy Nagirnyak commented on Planning for Rhino Mocks 4.0

Thu, 03 Sep 2009 23:36:18 GMT

Just my 2 cents. The API of RhinoMocks is actually one of the reasons I decided to use Moq. It was a bit complex to get started with. Moq provides intuitive and IntelliSense-ish way of doing things. I think it would be good idea to embrace Moq-like syntax with lambdas and the new .NET 4 features to simplify the API. One of the aims could be to "write less and do more".

Mark commented on Planning for Rhino Mocks 4.0

Thu, 03 Sep 2009 23:28:18 GMT

Sounds like a good idea to me. I feel RM does suffer a bit from having too many things; finding the 'best' way to do things turned up a lot of options to filter through. I'll definitely give a thumbs-up to a clean break. Furthermore, I also agree with killing the strict mock / mock / stub / partial terminology. In my experience, it complicates things a lot and tends to make the learning curve a lot steeper.

Jason commented on Planning for Rhino Mocks 4.0

Thu, 03 Sep 2009 22:28:15 GMT

I agree with this plan, I would appreciate a cleanup of the older stuff since I only use the AAA style. I also think this will lower the barrier to entry for developers that are new to mocking. Today when I hand new dev Rhino Mocks they get confused by the large API and I have to explain the history of the record/playback to the AAA. Keep up the great work Oren, we really apreciate it!

Wes McClure commented on Planning for Rhino Mocks 4.0

Thu, 03 Sep 2009 22:13:57 GMT

Simplicity rocks! I already am a huge fan of the current AAA syntax in Rhino Mocks.

Ayende Rahien commented on Planning for Rhino Mocks 4.0

Thu, 03 Sep 2009 21:43:56 GMT

Arrange, Act, Assert

Erik commented on Planning for Rhino Mocks 4.0

Thu, 03 Sep 2009 21:40:59 GMT

Could you define "AAA"?

Barry Dahlberg commented on Planning for Rhino Mocks 4.0

Thu, 03 Sep 2009 21:33:23 GMT

Excellent. What you described is probably the only thing I'd ask for anyway.

Ayende Rahien commented on Planning for Rhino Mocks 4.0

Thu, 03 Sep 2009 18:56:12 GMT

GREAT idea, Noel. Added it to the queue [http://github.com/ayende/rhino-mocks/issues](http://github.com/ayende/rhino-mocks/issues)

John Chapman commented on Planning for Rhino Mocks 4.0

Thu, 03 Sep 2009 18:48:22 GMT

Ayende, I completely agree that's the right move for the framework. Whenever I give a talk on Rhino Mocks I pretty much state to ignore all of the different terms, but offer to explain them afterwards if they are really curious. It has probably been the biggest confusion point with Rhino Mocks. I worry a little bit about completely abandoning the old concepts though. I wonder if it makes sense to create a deprecated repository class which exists for one release to make it easier for people who may have used those old concepts to migrate to the new versions. But really 3.6 works great, and people can keep using 3.6 forever, so don't upgrade unless you're prepared to rework your tests.

Ayende Rahien commented on Planning for Rhino Mocks 4.0

Thu, 03 Sep 2009 18:42:48 GMT

Dave, I would be delighted, we are having a conversation about that in the mailing list, you are welcome to join in

Bryan commented on Planning for Rhino Mocks 4.0

Thu, 03 Sep 2009 18:39:56 GMT

I suggest you put it in a different namespace and assembly. That way, we can easily have 3.6 and 4.0 live side by side in one test project. We can start using 4.0 for all new tests, and let old tests that still use 3.6 but are still valid rot.

Chris Brandsma commented on Planning for Rhino Mocks 4.0

Thu, 03 Sep 2009 18:39:43 GMT

I'm with everyone else here. I love the idea of simplifying the api down.

Radenko Zec commented on Planning for Rhino Mocks 4.0

Thu, 03 Sep 2009 18:20:12 GMT

Great plans. Sound good.

Noel Kennedy commented on Planning for Rhino Mocks 4.0

Thu, 03 Sep 2009 18:12:51 GMT

Completely agree with the strategy. How about including simple automocking 'container'? I don't really like the term 'container', but that's what the concept appears to be called atm! I have one which instantiates the sut by injecting fakes into the ctor. You then ask the container to return the stubs you want to set expectations on. Mine works a bit like this: var sut = mocks.MakeSut

Diego Mijelshon commented on Planning for Rhino Mocks 4.0

Thu, 03 Sep 2009 18:11:11 GMT

The design decisions seem 100% correct and aligned with the way people think about mocks these days. It'll be a lot more like Moq, though :-)