What do you all see as being the real trouble spots? For me it's the confusion around Mocks/Stubs...
What else? On Fri, Sep 4, 2009 at 10:08 AM, Ayende Rahien <[email protected]> wrote: > works for me as the basis for what we do, yes :-) > > > On Fri, Sep 4, 2009 at 6:02 PM, Tim Barcz <[email protected]> wrote: > >> I suggested this before (possibly in a different thread) >> >> but I would like to see the type inferred from usage. >> >> // Arrange >> var fake = Fake.Create<IFoo>(); >> fake.Stub(x=>x.Method()).Return("hello world"); >> >> // Act >> fake.Method() >> >> >> >> // Arrange >> var fake = Fake.Create<IFoo>(); >> fake.Stub(x=>x.Method()).Return("hello world"); >> >> // Act >> fake.Method() >> >> // Assert >> fake.AssertWasCalled(x=>x.Bar()) >> >> >> >> On Fri, Sep 4, 2009 at 9:29 AM, Ayende Rahien <[email protected]> wrote: >> >>> Ideally, I would like to get some ideas about the desired syntax and >>> capabilities.That will allow us to have better idea about what is >>> needed. >>> I intend to make use of a lot of the RM existing infrastructure, so it is >>> the surface behavior that interests me the most. >>> >>> On Fri, Sep 4, 2009 at 5:23 PM, Tim Barcz <[email protected]> wrote: >>> >>>> I too am curious on the organizing around this... >>>> >>>> Do we need/want to set up something like tickets or use AgileZen (or >>>> other tools) for project purposes? >>>> >>>> Tim >>>> >>>> >>>> On Fri, Sep 4, 2009 at 3:17 AM, Alex McMahon <[email protected]>wrote: >>>> >>>>> >>>>> Ayende, >>>>> >>>>> When you say "you are welcome to contribute" will you be organising >>>>> this in some way? will there be a list of tasks? >>>>> >>>>> I've not submitted a patch to Rhino Mocks before, but I'd be >>>>> interested in having a go at submitting one for 4.0. >>>>> >>>>> Do you think there will be tasks that could be tackled by someone >>>>> who's not already overly familiar with the code base? >>>>> >>>>> Regards >>>>> Alex McMahon >>>>> >>>>> 2009/9/1 Ayende Rahien <[email protected]>: >>>>> > This is a blog post that would show up day after tomorrow, I am >>>>> posting it >>>>> > here to get some traction in the mailing list before we make it >>>>> really >>>>> > public. >>>>> > >>>>> > Well, now that Rhino Mocks 3.6 is out of the way, we need to think >>>>> about >>>>> > what the next version will look like. >>>>> > >>>>> > Initially, I thought to match Rhino Mocks 4.0 to the .NET 4.0 release >>>>> and >>>>> > support mocking dynamic variables, but while this is still on the >>>>> planning >>>>> > board, I think that it is much more important to stop and take a look >>>>> at >>>>> > where Rhino Mocks is now and where we would like it to be. >>>>> > >>>>> > I started Rhino Mocks about 5 years ago, and the codebase has stood >>>>> well in >>>>> > the test of time. There aren’t any nasty places and we can keep >>>>> releasing >>>>> > new features with no major issues. >>>>> > >>>>> > However, 5 years ago the community perception of mocking was >>>>> different than >>>>> > what it is now. Rhino Mocks hasn’t really changed significantly since >>>>> it 1.1 >>>>> > days, for that matter, you can take a code base using Rhino Mocks for >>>>> .Net >>>>> > 1.1 and move it to Rhino Mocks 3.6 with no issues. >>>>> > >>>>> > But one of the most frequent complaints that I have heard is that >>>>> Rhino >>>>> > Mocks API has became too complex over the years, there are too many >>>>> options >>>>> > and knobs that you can turn. I know that my own style of interaction >>>>> testing >>>>> > has changed as well. >>>>> > >>>>> > The current plan for Rhino Mocks 4.0 is that we will break backward >>>>> > compatibility in a big way. That means that we are going to >>>>> drastically >>>>> > simplify everything in the framework. >>>>> > >>>>> > We are still discussing this in the mailing list, but currently it >>>>> looks >>>>> > like we will go with the following route: >>>>> > >>>>> > Kill the dynamic, strict, partial and stub terminology. No one cares. >>>>> It is >>>>> > a fake. >>>>> > Remove the record / playback API. The AAA method is much simpler. >>>>> > Simplify mocking options, aiming at moving as much as possible from >>>>> > expectation style to assert style. >>>>> > Keep as much of the current capabilities as we can. That means that >>>>> if Rhino >>>>> > Mocks was able to support a scenario, it should still support it for >>>>> the 4.0 >>>>> > version, hopefully in a simpler fashion. >>>>> > >>>>> > The end result is putting Rhino Mocks on an API diet. I am looking >>>>> for help >>>>> > in doing this, both in terms of suggested syntax and in terms of >>>>> actual >>>>> > patches. >>>>> > >>>>> > You are welcome to contribute… >>>>> > >>>>> > > >>>>> > >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Tim Barcz >>>> Microsoft ASPInsider >>>> http://timbarcz.devlicio.us >>>> http://www.twitter.com/timbarcz >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> -- >> Tim Barcz >> Microsoft ASPInsider >> http://timbarcz.devlicio.us >> http://www.twitter.com/timbarcz >> >> >> >> > > > > -- Tim Barcz Microsoft ASPInsider http://timbarcz.devlicio.us http://www.twitter.com/timbarcz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino.Mocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rhinomocks?hl=en -~----------~----~----~----~------~----~------~--~---
