Alex, You are entirely correct. The record / replay syntax is the only syntax I have picked up through top links from google since looking at mocking for the last couple of months. It's only this week when looking at contraints have I found the new syntax which looks a little scary, especially when I have only 3 days left to complete my current project.
On Nov 17, 8:14 pm, Alex McMahon <[email protected]> wrote: > I've been thinking the same. I think it's because the documentation about > AAA syntax is a bit hiddenhttp://www.ayende.com/wiki/Rhino+Mocks+3.5.ashx. > And when you google for "rhino mocks documentation" you end up here: > > http://www.ayende.com/wiki/Rhino+Mocks+Documentation.ashx > > which is all old syntax, and what's more it has a simple example that uses > StrictMock!! oh dear. > > In fact it's pretty difficult to get to the AAA documentation from there. > The easiest fix is probably to add a link the AAA syntax to this > documentation page. And to say that this is the highly recommended approach. > The slightly better change is probably to rearrange the documentation so > that the 3.5 changes are incorporated and then to order the sections so AAA > is the obvious answer, and also to mark all old syntaxes as not recommended. > > 2009/11/17 Tim Barcz <[email protected]> > > > > > > > Where are people new to Rhino learning about record/replay? > > > I'd like to find/fix. > > > Tim > > > On 11/17/09, Alex McMahon <[email protected]> wrote: > > > My response: > > > > 1. I don't see what's wrong with testing it the way you are at the > > > moment. > > > 2. If you really don't like it then I'd take a look at > > > http://www.ayende.com/wiki/Rhino+Mocks+3.5.ashx#ArgumentConstraints > > > 3. Also is there any reason you are using StrictMocks? it's almost > > always > > > a 'bad idea' > > > 4. Any reason why you're using the old record/replay syntax? I'd > > always > > > recommend using the AAA syntax (Arrange Act Assert) > > > > 2009/11/17 Goatified Creature <[email protected]> > > > >> Hi Guys, > > > >> Sorry to bump, I just wondered whether I had commited a terrible sin, > > >> or maybe my question is a little dumb!! > > > >> Cheers! > > > >> On Nov 16, 2:52 pm, Goatified Creature <[email protected]> > > >> wrote: > > >> > Hi, I have been trying to write a unit test in C# for a Manager > > >> > method. I am mocking two DAOS. However, the parameter passed to the > > >> > manager method will be further populated by the manager and passed as > > >> > an argument to one DAO. I wish to place a constraint on the DAO call > > >> > to ensure this property was populated correctly. Maybe this is easier > > >> > to demonstrate through code.... > > > >> > // the manager to test > > >> > SearchManager managerToTest = new SearchManager(); > > > >> > // mock the two DAOs > > >> > MockRepository mocks = new MockRepository(); > > >> > ISearchDAO mockedSearchDAO = mocks.StrictMock<ISearchDAO> > > >> > (); > > >> > IServiceAreaDAO mockedServiceAreaDAO = > > >> > mocks.StrictMock<IServiceAreaDAO>(); > > > >> > // create a search criteria object that does not have it's > > >> > ServiceAreas collection populated > > >> > ArticleSearchCriteria criteria = new ArticleSearchCriteria > > >> > (); > > > >> > // now the manager method will populate the ServiceAreas > > >> > property of criteria with a collection of > > >> > // matching ServiceArea objects matching the below int > > >> > array > > >> > int[] serviceAreaIds = { 345435 }; > > >> > ServiceArea serviceArea = new ServiceArea(); > > > >> > // and these will be the pretend results > > >> > ArticleSearchResult resultFromDAO = new > > ArticleSearchResult > > >> > (); > > > >> > using (mocks.Record()) > > >> > { > > >> > Expect.Call(mockedServiceAreaDAO.GetById > > >> > (345435)).Return(serviceArea); > > > >> > // Now, here, I want a contraint to say > > >> > // ensure criteria.ServiceAreas contains the above > > >> > serviceArea object. This will be > > >> > // set before calling the below DAO method. > > >> > Expect.Call(mockedSearchDAO.SearchForArticles > > >> > (criteria)).Return(resultFromDAO); > > > >> > } > > >> > using (mocks.Playback()) > > >> > { > > >> > // inject DAO dependencies > > >> > managerToTest.SearchDAO = mockedSearchDAO; > > >> > managerToTest.ServiceAreaDAO = mockedServiceAreaDAO; > > > >> > // call the method ensuring correct results. This > > >> > works fine > > >> > Assert.That(managerToTest.SearchForArticles(criteria, > > >> > serviceAreaIds), Is.SameAs(resultFromDAO)); > > > >> > // Now, I shouldn't be validating the ServiceAreas > > >> > collection was populated through the assert methodology > > >> > Assert.That(criteria.ServiceAreas, Has.Member > > >> > (serviceArea)); > > >> > } > > > >> > I have been tearing my receding hair out all afternoon through the > > >> > Rhino Mocks documentation to understand how to test this scenario. > > > >> > Cheers!!! > > > -- > > Sent from my mobile device > > > Tim Barcz > > Microsoft C# MVP > > 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 -~----------~----~----~----~------~----~------~--~---
