Re: Statics and caches and mocks oh my!

I just want to add that you might need to convince your coworkers to keep unit tests passing. 

If they are further convinced of the usefulness of writing tests, then you can show them up how helpful refactoring for testability is.

--
C. Keith Ray
* 650-533-6535
* https://dl.dropbox.com/u/686328/keith_ray_resume.pdf
* http://agilesolutionspace.blogspot.com/

On 2013 Jun 27, at 6:51 AM, Russell Gold <[email protected]> wrote:

> How much code control does the organization exert? Do you have regular code reviews?
> 
> My experience is that the best way is to start small. Make one class testable at a time without touching the caches. Use facade interfaces as wrappers to deal with your statics. For example, in Java I might do something like this:
> 
> Existing static:
> 
> public static ThingIWant getThingIWant() { accesses the db and caches the result }
> 
> Existing class:
> 
> class MyClass {
> 
> :
> 
> void doSomething() {
> ThingIWant aThing = ThatStaticClass.getThingIWant();
> process(aThing);
> }
> }
> 
> Modified class
> 
> class MyClass {
> interface SomeInterface {
> ThingIWant getThingIWant();
> }
> 
> static class LiveProxy implements SomeInterface {
> public ThingIWant getThingIWant() {
> return ThatStaticClass.getThingIWant();
> }
> }
> 
> // test constructor
> MyClass(SomeInterface interface) {
> this.interface = interface;
> }
> 
> // production constructor
> public MyClass() {
> this(new LiveProxy())
> }
> 
> /// modified method
> void doSomething() {
> ThingIWant aThing = this.interface.getThingIWant();
> process(aThing);
> }
> 
> Your code is now testable - you supply a test version of the interface when you instantiate it, and can control the object returned. The production code uses the same interface, but supplies a production version which accesses the statics. You don't need to persuade anybody of anything, other than your code reviewers. The rest of the system remains unchanged. 
> 
> At some point in the future, once you have an acceptable level of code coverage, you can tackle changing the statics, but I'd put that off as long as possible. 
> 
> The important thing is to start by testing as much as you can while making as few changes as possible.
> 
> - Russ
> 
> 
> On Jun 27, 2013, at 2:59 AM, David Burstin <[email protected]> wrote:
> 
> > As far as code smells go, some people just seem to have blocked noses!
> > 
> > Anyway, thanks everyone for your answers. I'm glad to see that I am on the
> > right track - now I just have to convince everyone else. I think the best
> > way forward is baby steps. I will start by encapsulating the statics inside
> > a concrete implementation with a well-defined interface. Even that might
> > take some convincing! But at least it will give the opportunity to do some
> > good testing.
> > 
> > I am looking at the possibility of using a DI framework to replace the
> > singleton caches, but that will be a HUGE leap for these guys. What do you
> > guys feel is the best strategy for caching without having to pass around an
> > entire collection of cache instances?
> > 
> > 
> > Cheers
> > David
> > 
> > 
> > On 27 June 2013 04:24, Steven Gordon <[email protected]> wrote:
> > 
> >> 
> >> 
> >> On Wed, Jun 26, 2013 at 10:54 AM, Michal Svoboda <[email protected]> wrote:
> >> 
> >>> **
> >>> 
> >>> 
> >>>> Everyone else on the team thinks that they are a great solution.
> >>> 
> >>> I hear you. It's not easy to convince others of their design problems
> >>> unless there is hard factual evidence. Look around the user code of that
> >>> object and you'll find the smells.
> >>> 
> >> 
> >> Or there might not be any convincing enough smells, yet!
> >> 
> >> If not, bide your time, watch for smells as the code scales, and when
> >> convincing smells appear, then make the case for refactoring it away
> >> (trying not to say "I told you so").
> >> 
> >> One benefit is that there may be more information later to indicate what
> >> the most appropriate alternative would be.
> >> 
> >> SteveG
> >> 
> >> 
> >>> 
> >>> Michal Svoboda
> >>> 
> >>> 
> >>> 
> >> 
> >> 
> > 
> > 
> > [Non-text portions of this message have been removed]
> > 
> > 
> > 
> > ------------------------------------
> > 
> > Yahoo! Groups Links
> > 
> > 
> > 
> 
> -----------------
> Come read my webnovel, Take a Lemon <http://www.takealemon.com>, 
> and listen to the Misfile radio play <http://www.gold-family.us/audio/misfile.html>!
> 
> [Non-text portions of this message have been removed]
> 
> 



[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/