Yep that worked ok.
Now, to change the subject very slightly, now I am understanding the
one assert per test strategy, what tests would be recommended for
testing the following pseaudo method:
public Result SearchAgainstSeveralSystems (string SearchTerm)
{
System1Result = System1.Search(SearchTerm);
System2Result = System2.Search(SearchTerm);
Result result = new Result;
Result.SystemResults.Add(System1Result);
Result.SystemResults.Add(System2Result);
}
my understanding would be make sure you hit the various systems:
search_that_system1_is_searched_against (mocking system1, and stubbing
system2 and result.SystemResults.Add
search_that_system2_is_searched_against (mocking system2, and stubbing
system1 and result.SystemResults.Add
then, maybe 2 searches for
search_that_results_get_added_to_results (stubbing both systems and
mocking the result.SystemResults.Add method expecting two invocations)
Then, should there be a test that asserts the returned result is the
result object? Suppose not as its just a return command but I could
always mistakenly return another Result object.
Alternatively, instead of mocking the result.SystemResults.Add method,
I could simply do a couple of tests that Assert(result.SystemResults
[0], Is.SameAs (a dummy object returned from stubbed systems).
Does this make sense? Problem is that the test doesn't have a handle
to the Result object and therefore, can't have a direct assert against
it.
Cheers
On Nov 18, 3:43 pm, Patrick Steele <[email protected]> wrote:
> If ArticleSearchCriteria has virtual members, I think you could mock
> the ServiceAreas collection and set an expectation on the "Add"
> method. Assuming you have something like this:
>
> class ArticleSearchCriteria
> {
> public virtual IList<ServiceArea> ServiceAreas { get; set; }
>
> }
>
> You could create a mock IList<ServiceArea> and set an expectation on
> the Add method. Then stub ArticleSearchCritera.ServiceAreas property
> to return your mocked IList<ServiceArea> (below is AAA syntax and
> typed on-the-fly):
>
> var saList = MockRepository.GenerateMock<IList<ServiceArea>>();
> var searchCriteria = MockRepository.GenerateStub<ArticleSearchCriteria>();
> s.ServiceAreas = saList; // I think you can just do the assign with AAA syntax
>
> Now tell Rhino mocks you expect an Add of your resultFromDAO:
>
> saList.Expect(c => c.Add(resultFromDAO));
>
> I think that'll get you going.
>
> ---
> Patrick Steelehttp://weblogs.asp.net/psteele
>
> On Wed, Nov 18, 2009 at 9:50 AM, Goatified Creature
>
> <[email protected]> wrote:
> > Exactly! I want!!! However, i was struggling to find an appropriate
> > Contraint to meet this. I am now looking at the AAA syntax and
> > attempting to follow the test one thing per test strategy, but it's
> > difficult when you pick up bad habits!!!
>
> > On Nov 18, 12:39 pm, Patrick Steele <[email protected]> wrote:
> >> Let me see if I understand exactly what you want (ironically, I
> >> learned RhinoMocks with the AAA syntax and I find it hard sometimes to
> >> follow the record/play syntax). The SearchManager class you're
> >> testing has the following members:
>
> >> ISearchDAO SearchDAO { get; set; }
> >> IServiceAreaDAO ServiceAreaDAO { get; set; }
> >> ArticleSearchResult SearchForArticles(ArticleSearchCriteria criteria,
> >> int[] serviceAreaIds)
>
> >> You want to ensure that the when calling SearchForArticles, the
> >> results of any calls made to ServiceAreaDAO.GetById(int) are added to
> >> the criteria.ServiceAreas collection?
>
> >> --
> >> Patrick Steelehttp://weblogs.asp.net/psteele
>
> >> On Mon, Nov 16, 2009 at 9:52 AM, 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!!!
--
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].
For more options, visit this group at
http://groups.google.com/group/rhinomocks?hl=.
