Not sure if this will be helpful or just noise, but, generally speaking what I try to do when I'm tackling the issue of mocking data access components is that I encapsulate the data access inside another layer. Typically I call the class FooDataProvider and implement an interface for it. The method should take the search parameters for get calls and return only "local" objects (i.e. it shouldn't return DataSets or framework generated objects) and should take "local" objects for "Save" calls. Inside the data provider, it should do all the translation between your app code and the data provider. This provides full isolation from your data layer (i.e. abstracting away from where data is coming from), but most importantly, it provides you the interface you need for mocking.
Again, not sure if that helps or if that's just noise, but I thought I'd throw that out there for consideration. On Wed, Nov 19, 2014 at 7:58 AM, Peter Finch <[email protected]> wrote: > I'll give that a go. I will just try to test HistoryEntry on it's own to > see what happens. > > Many thanks > > -- > You received this message because you are subscribed to the Google Groups > "Rhino.Mocks" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/rhinomocks. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Rhino.Mocks" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rhinomocks. For more options, visit https://groups.google.com/d/optout.
