Re: Statics and caches and mocks oh my!

Hi Steve. Thanks for the links. I had a look at the blog and unless I am
mistaken it is still just using a static cache internally -
HttpRuntime.Cache.

Am I missing something?
On 29/06/2013 12:55 AM, "Steve Smith" <[email protected]> wrote:

> I would avoid the statics, replace the references to the repositories with
> interfaces, and also split the responsibility to cache or access data into
> two pieces, so that each can be tested (and evolve) independently.  For
> more on this last part, see my article series on the CachedRepository
> pattern:
>
> http://ardalis.com/introducing-the-cachedrepository-pattern
>
> If you happen to have a Pluralsight subscription (or grab the free trial)
> there's a 6 minute demo showing this implementation as part of the Proxy
> Design Pattern course, here:
> http://pluralsight.com/training/Courses/TableOfContents/patterns-library
>
> Cheers,
> Steve
>
>
> On Wed, Jun 26, 2013 at 10:52 AM, David Burstin <[email protected]
> >wrote:
>
> > **
> >
> >
> > Hi folks,
> >
> > I've got a question around design for a legacy project that I am working
> on
> > in c#.
> >
> > This project uses some repository classes that internally act as caches,
> > retrieving data from internal lists and only hitting the database if the
> > items are not found. These are all implemented as static methods -
> > effectively acting as globals. The static repositories provide the
> benefits
> > of global accessibility throughout the project as well as a single
> internal
> > long-lived cache.
> >
> > My problem is that I am trying to test some classes that use these
> > repositories as collaborators, but don't have a good way of
> mocking/faking
> > the repositories as (a) they don't have any interfaces and (b) they are
> not
> > instances, so cannot be injected.
> >
> > One option is to add static methods to the repositories to inject canned
> > data into their internal lists for testing, but that seems wrong to me -
> it
> > exposes their internal implementation and breaks encapsulation (is there
> > such a thing with static objects?).
> >
> > Another is to create an interface and have the production code use a
> > concrete implementation that internally calls the static methods.In
> testing
> > I can inject mocks. Again, this seems messy to me.
> >
> > I personally don't like the use of static objects, but I don't know what
> a
> > better alternative is that would provide long-lived caching and easy
> > accessibility from anywhere in the code. Everyone else on the team thinks
> > that they are a great solution.
> >
> > What do you guys think? Is there a good way to test this scenario that I
> am
> > missing? Or is the design smelly as I suspect?
> >
> > Cheers
> > David
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
>
>
>
> --
> Steve Smith
> http://Ardalis.com/
> http://twitter.com/ardalis
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/