the point of creating the AdapterCollection object is to make your code testable, not test the 3rd party framework. in this instance I would not write a test for this. at most I would create a new ThirdPartyCollection<T>() and test against an actual collection, not a mock.
On Sep 30, 5:30 am, haifisch <[email protected]> wrote: > Hello, > > i've writen a adapter from a 3rd-party-collection to ICollection<T> - > lets take a look at the code... > > internal class AdapterCollection<T, TInterface> : > ICollection<TInterface> where T : class, TInterface > { > private ThirdPartyCollection<T> collection; > > public AdapterCollection(ThirdPartyCollection<T> collection) > { > this.collection = collection; > } > > public int Count > { > get > { > if (this.collection.GetSomeInfluenceableState()) > { > return this.collection.Where("true").Count; > } > else > { > return this.collection.Count; > } > } > } > > I now want to write unit-tests for the Count-property. But how to do > that? > Note that the ThirdPartyCollection is a collection from a persistence > framework. > > I couldn't use behaviour verification, because i couldn't mock a call > to "Where" since it is a non-virtual method. > > I also couldn't (at least directly) use state verification, because a > real 'ThirdPartyCollection' instance will return the same Count in > both branches (only the way the Count is determined differs). > > What do you think about such a scenario? Did i make some mistake in > the design of my adapter? > Is there a chance to rewrite the code to make it (more) testable? > > Best regards, > > Andreas Ländle --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
