Hi Jason, i couldn't test against a actual collection - since the observable behaviour doesn't differ. Ok, i could write a 'just works anyway' test - but that would be quite meaningless.
I'll follow your adivice and would not write unit-tests for my adapter (since it's code is pretty simple). Just to continue the discussion: Would it be worth to consider the use of something like 'typemock isolator' or 'microsoft stubs/moles' in such situations (to "stub" the non-virtual method call)? Or is it o.k. that code that only acts as a seam to the outside world (3rd-party components, databases, web- services, etc.) isn't covered by 'real' unit-tests? Maybe its enough to check that code by some 'layer-crossing' integration tests (even if some internal behaviour is not observable/testable)? Whats your experiences? Best regards, Andreas Ländle On 30 Sep., 14:14, Jason Meckley <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
