Gavin, Patrick is not suggesting that you don't use objects, he has just used strings in his example for simplicity's sake.
On May 6, 8:22 am, Gavin van der Merwe <[email protected]> wrote: > Sorry guys just to re-iterate because I think my last email did not give > much context > > To quote Patrick > > *""Ok, here's an approach I would take. > > You want to make sure that your FooProvider will not return any of the > blacklisted items. That's the behavior you want to test. Here's how > I would see as one approach to testing this. For simplicity, I'll use > strings instead of Foo instances, but the concept is the same. I also > assume you've got some kind of a repository layer that you can stub > out so you're not hitting the DB during your unit tests.""* > * > * > Question: > > Why would you suggest not using objects for your blacklisted items? > Surely objects can be mapped using NHibernate and overriding equals would > sort out equality operations? > > On 5 May 2011 18:53, Gavin van der Merwe <[email protected]> wrote: > > > > > Really so why would you not suggest an override for equals and gethashcode? > > > On May 5, 2011 4:18 PM, "Giulio Petrucci" <[email protected]> > > wrote: > > > Hi Patrick, > > > > first of all, thanks for your reply. > > > > On Thu, May 5, 2011 at 1:44 PM, Patrick Steele <[email protected]> > > wrote: > > >> You want to make sure that your FooProvider will not return any of the > > >> blacklisted items. > > > > Uhm... almost. :-) > > > >> I also > > >> assume you've got some kind of a repository layer that you can stub > > >> out so you're not hitting the DB during your unit tests. > > > > Of course. The repository layer is represented from the IDataContext > > > interface of which I wrote previously in the thread. > > > >> // arrange > > >> IRepository repository = MockRepository.GenerateStub<IRepository>(); > > >> var fooProvider = new FooProvider(repository); > > >> fooProvider.BlackList = new [] { "A", "E", "I" }; > > >> repository.Stub(r => r.GetNext10Items()).Return(new [] { "A", "B", > > >> "C", "D", "E"}); > > > >> // act > > >> var result = fooProvider.GetItems(); // internally calls > > >> repository.GetNext10Items() > > > >> // assert > > >> Assert.AreEqual(3, result.Count); > > >> Assert.IsTrue(result.Contains("B"); > > >> Assert.IsTrue(result.Contains("C"); > > >> Assert.IsTrue(result.Contains("D"); > > > > Ok, there something I don't like: it seems like I'm testing the > > > List<T>.Contains() method. In fact using this approach (which is quite > > > > black-box oriented) I cannot verify that at a certain point and under > > > some conditions the List<T>.Contains() method is called, even if I can > > > verify the effect of that call. Now, as I'm quite new to advanced > > > unit-testing I ask: is it just a problem of mine? ;-) > > > > Thanks, > > > Giulio > > > > -- > > > > -- > > > 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.- Hide quoted text - > > - Show quoted text - -- 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.
