Test for Singleton class

[shagil]

Hi experts,

Could anyone please suggest how to write a test class for Singleton class?

Thanks
Shagi



     

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

[Steven Smith-23]

You have several options, but in general Singleton is a pattern to avoid for
testability reasons.
Things I've done in the past to make this work:
1) Add a method to reset the Singleton Instance (e.g. public static Reset()
{ this.Instance = new Foo(); } ), and call this in your Setup() method for
your tests.

2) Alternately, leave a public constructor on the class (and optionally mark
it with an attribute explaining it should only be used in tests, e.g.
[Obsolete("Only call from tests.")].  New up the instances as usual in your
tests.

Steve



On Thu, Oct 15, 2009 at 8:58 AM, shagil <shagil_t@...> wrote:

>
>
> Hi experts,
>
> Could anyone please suggest how to write a test class for Singleton class?
>
> Thanks
> Shagi
>
> [Non-text portions of this message have been removed]
>
>  
>

--
Steve Smith
http://SteveSmithBlog.com/
http://twitter.com/ardalis


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

[Nat Pryce]

2009/10/15 shagil <shagil_t@...>
> Could anyone please suggest how to write a test class for Singleton class?

I'd make it not use the Singleton pattern. Instead I'd just create a
single instance in the real system and pass it to constructors of the
objects that need to use it.  And create as many throw-away instances
in unit tests as necessary.

--Nat

--
http://www.natpryce.com

[Adam Sroka-3]

On Thu, Oct 15, 2009 at 1:19 PM, Nat Pryce <nat.pryce@...> wrote:

>
>
>
> 2009/10/15 shagil <shagil_t@...>
>
> > Could anyone please suggest how to write a test class for Singleton class?
>
> I'd make it not use the Singleton pattern. Instead I'd just create a
> single instance in the real system and pass it to constructors of the
> objects that need to use it.  And create as many throw-away instances
> in unit tests as necessary.
>

I agree with Nat. Better to not create a Singleton class, but if you
want to control instantiation control it above the class. For example,
Spring allows you to annotate a class as being scoped to a Singleton.
In that model the class is just a regular java class, but Spring
enforces that it behaves like a Singleton.

I'm not saying that you need to use Spring, necessarily (Or whatever
the equivalent in your language might be.) However, perhaps another
class controls instantiation (e.g. a builder or abstract factory) and
your "singleton" is just a plain-old class.

On the other hand, if you /really/ want to use the Singleton pattern
as it has been described elsewhere you just need a way to destroy it
after you have created it. Then you should be able to test it like any
other class. There are a number of ways to do that, the simplest being
to make the default constructor public. Another would be to have the
factory return a non-final reference that you could nullify. Another
would be to have an explicit "destroy" method that removes the single
instance... I'm sure there are others.

[Adam Sroka-3]

On Thu, Oct 15, 2009 at 1:40 PM, Adam Sroka <adam.sroka@...> wrote:

> On Thu, Oct 15, 2009 at 1:19 PM, Nat Pryce <nat.pryce@...> wrote:
>>
>>
>>
>> 2009/10/15 shagil <shagil_t@...>
>>
>> > Could anyone please suggest how to write a test class for Singleton class?
>>
>> I'd make it not use the Singleton pattern. Instead I'd just create a
>> single instance in the real system and pass it to constructors of the
>> objects that need to use it.  And create as many throw-away instances
>> in unit tests as necessary.
>>
>
> I agree with Nat. Better to not create a Singleton class, but if you
> want to control instantiation control it above the class. For example,
> Spring allows you to annotate a class as being scoped to a Singleton.
> In that model the class is just a regular java class, but Spring
> enforces that it behaves like a Singleton.
>
> I'm not saying that you need to use Spring, necessarily (Or whatever
> the equivalent in your language might be.) However, perhaps another
> class controls instantiation (e.g. a builder or abstract factory) and
> your "singleton" is just a plain-old class.
>
> On the other hand, if you /really/ want to use the Singleton pattern
> as it has been described elsewhere you just need a way to destroy it
> after you have created it. Then you should be able to test it like any
> other class. There are a number of ways to do that, the simplest being
> to make the default constructor public. Another would be to have the
> factory return a non-final reference that you could nullify. Another
> would be to have an explicit "destroy" method that removes the single
> instance... I'm sure there are others.
>

P.S. It's also worth considering what your motivation is for creating
a Singleton in the first place. Usually a Singleton is just a way to
store global state, and there is some consensus in the design
community that this is a Bad Thing (Especially in a multi-core,
multi-threaded system.)

[Corey Haines]

While I am a firm opponent of even thinking about using a singleton, here is
a nice video that Brandon Joyce did on TDD-ing a singleton:
http://vimeo.com/3182499

On Thu, Oct 15, 2009 at 4:00 PM, Adam Sroka <adam.sroka@...> wrote:

>
>
> On Thu, Oct 15, 2009 at 1:40 PM, Adam Sroka <adam.sroka@...<adam.sroka%40gmail.com>>
> wrote:
> > On Thu, Oct 15, 2009 at 1:19 PM, Nat Pryce <nat.pryce@...<nat.pryce%40gmail.com>>
> wrote:
> >>
> >>
> >>
> >> 2009/10/15 shagil <shagil_t@... <shagil_t%40yahoo.com>>
> >>
> >> > Could anyone please suggest how to write a test class for Singleton
> class?
> >>
> >> I'd make it not use the Singleton pattern. Instead I'd just create a
> >> single instance in the real system and pass it to constructors of the
> >> objects that need to use it.  And create as many throw-away instances
> >> in unit tests as necessary.
> >>
> >
> > I agree with Nat. Better to not create a Singleton class, but if you
> > want to control instantiation control it above the class. For example,
> > Spring allows you to annotate a class as being scoped to a Singleton.
> > In that model the class is just a regular java class, but Spring
> > enforces that it behaves like a Singleton.
> >
> > I'm not saying that you need to use Spring, necessarily (Or whatever
> > the equivalent in your language might be.) However, perhaps another
> > class controls instantiation (e.g. a builder or abstract factory) and
> > your "singleton" is just a plain-old class.
> >
> > On the other hand, if you /really/ want to use the Singleton pattern
> > as it has been described elsewhere you just need a way to destroy it
> > after you have created it. Then you should be able to test it like any
> > other class. There are a number of ways to do that, the simplest being
> > to make the default constructor public. Another would be to have the
> > factory return a non-final reference that you could nullify. Another
> > would be to have an explicit "destroy" method that removes the single
> > instance... I'm sure there are others.
> >
>
> P.S. It's also worth considering what your motivation is for creating
> a Singleton in the first place. Usually a Singleton is just a way to
> store global state, and there is some consensus in the design
> community that this is a Bad Thing (Especially in a multi-core,
> multi-threaded system.)
>  
>

--
http://www.coreyhaines.com
The Internet's Premiere source of information about Corey Haines


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

[Mauricio Aniche]

Hi,

There is no easy way to test a singleton class. You can create two classes,
one is the singleton and the other has your program code in which you want
to test. You can hide this class by putting them into the same package and
playing around with their visibility. The singleton class only takes care of
creating one instance the regular class.

Then, you can test the regular class in the way you are used to.

PS: But i would think again about your design. Singletons are not good. The
fact that a singleton is hard to test is one alert that something is not
right.

Regards,
Mauricio Aniche
Master Candidate in Computer Science
University of São Paulo
www.aniche.com.br

On Thu, Oct 15, 2009 at 7:07 PM, Corey Haines <coreyhaines@...> wrote:

>
>
> While I am a firm opponent of even thinking about using a singleton, here
> is
> a nice video that Brandon Joyce did on TDD-ing a singleton:
> http://vimeo.com/3182499
>
> On Thu, Oct 15, 2009 at 4:00 PM, Adam Sroka <adam.sroka@...<adam.sroka%40gmail.com>>
> wrote:
>
> >
> >
> > On Thu, Oct 15, 2009 at 1:40 PM, Adam Sroka <adam.sroka@...<adam.sroka%40gmail.com>
> <adam.sroka%40gmail.com>>
> > wrote:
> > > On Thu, Oct 15, 2009 at 1:19 PM, Nat Pryce <nat.pryce@...<nat.pryce%40gmail.com>
> <nat.pryce%40gmail.com>>
> > wrote:
> > >>
> > >>
> > >>
> > >> 2009/10/15 shagil <shagil_t@... <shagil_t%40yahoo.com><shagil_t%
> 40yahoo.com>>
>
> > >>
> > >> > Could anyone please suggest how to write a test class for Singleton
> > class?
> > >>
> > >> I'd make it not use the Singleton pattern. Instead I'd just create a
> > >> single instance in the real system and pass it to constructors of the
> > >> objects that need to use it. And create as many throw-away instances
> > >> in unit tests as necessary.
> > >>
> > >
> > > I agree with Nat. Better to not create a Singleton class, but if you
> > > want to control instantiation control it above the class. For example,
> > > Spring allows you to annotate a class as being scoped to a Singleton.
> > > In that model the class is just a regular java class, but Spring
> > > enforces that it behaves like a Singleton.
> > >
> > > I'm not saying that you need to use Spring, necessarily (Or whatever
> > > the equivalent in your language might be.) However, perhaps another
> > > class controls instantiation (e.g. a builder or abstract factory) and
> > > your "singleton" is just a plain-old class.
> > >
> > > On the other hand, if you /really/ want to use the Singleton pattern
> > > as it has been described elsewhere you just need a way to destroy it
> > > after you have created it. Then you should be able to test it like any
> > > other class. There are a number of ways to do that, the simplest being
> > > to make the default constructor public. Another would be to have the
> > > factory return a non-final reference that you could nullify. Another
> > > would be to have an explicit "destroy" method that removes the single
> > > instance... I'm sure there are others.
> > >
> >
> > P.S. It's also worth considering what your motivation is for creating
> > a Singleton in the first place. Usually a Singleton is just a way to
> > store global state, and there is some consensus in the design
> > community that this is a Bad Thing (Especially in a multi-core,
> > multi-threaded system.)
> >
> >
>
> --
> http://www.coreyhaines.com
> The Internet's Premiere source of information about Corey Haines
>
>
> [Non-text portions of this message have been removed]
>
>  
>

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

[James Carr]

Hi,

On Thu, Oct 15, 2009 at 3:07 PM, Corey Haines <coreyhaines@...> wrote:
> While I am a firm opponent of even thinking about using a singleton

+1
I've come to learn that using singletons in the classical way is
wrong... don't go creating static methods that return single instances
and seep into the code all over, it's just a recipe for epic disaster.
:)

More often than not, I find simple dependency injection often lessens
my need for singletons. If I can't do that, wrapping it inside of a
factory with non-static methods at least lessens the damage until I
can refactor. :)

[Bill Arnette]

But isn't a factory, service repository, whatever, eventually implemented as
a singleton?

On Thu, Nov 19, 2009 at 1:52 PM, James Carr <james.r.carr@...> wrote:

>
>
> Hi,
>
> On Thu, Oct 15, 2009 at 3:07 PM, Corey Haines <coreyhaines@...<coreyhaines%40gmail.com>>
> wrote:
> > While I am a firm opponent of even thinking about using a singleton
>
> +1
> I've come to learn that using singletons in the classical way is
> wrong... don't go creating static methods that return single instances
> and seep into the code all over, it's just a recipe for epic disaster.
> :)
>
> More often than not, I find simple dependency injection often lessens
> my need for singletons. If I can't do that, wrapping it inside of a
> factory with non-static methods at least lessens the damage until I
> can refactor. :)
>  
>

--
Bill Arnette


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

[Roy Osherove]

what if you created that singleton in ruby?
would it still be bad?

On Thu, Nov 19, 2009 at 8:52 PM, James Carr <james.r.carr@...> wrote:

>
>
> Hi,
>
>
> On Thu, Oct 15, 2009 at 3:07 PM, Corey Haines <coreyhaines@...<coreyhaines%40gmail.com>>
> wrote:
> > While I am a firm opponent of even thinking about using a singleton
>
> +1
> I've come to learn that using singletons in the classical way is
> wrong... don't go creating static methods that return single instances
> and seep into the code all over, it's just a recipe for epic disaster.
> :)
>
> More often than not, I find simple dependency injection often lessens
> my need for singletons. If I can't do that, wrapping it inside of a
> factory with non-static methods at least lessens the damage until I
> can refactor. :)
>
>  
>

--
Thanks,

Roy Osherove
www.TypeMock.com - Unit Testing, Plain Smart

Author of "The Art Of Unit Testing" (http://ArtOfUnitTesting.com )
A blog for team leaders: http://5Whys.com
my .NET blog: http://www.ISerializable.com
Twitter: http://twitter.com/RoyOsherove
[phone] (GMT+2)


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

[Angel Java Lopez]

Hi people!

Hmmm...IMO, a singleton could be tested ("easier") if it has no state. As
any static method in a class.

Another kind of singleton that could be tested, are "thread-safe" ones (that
is, with state, but written to be thread-safe). The problem is to
assert/prove that component is REALLY thread-safe.

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

On Thu, Nov 19, 2009 at 12:02 AM, Mauricio Aniche
<mauricioaniche@...>wrote:

>
>
> Hi,
>
> There is no easy way to test a singleton class. You can create two classes,
> one is the singleton and the other has your program code in which you want
> to test. You can hide this class by putting them into the same package and
> playing around with their visibility. The singleton class only takes care
> of
> creating one instance the regular class.
>
> Then, you can test the regular class in the way you are used to.
>
> PS: But i would think again about your design. Singletons are not good. The
> fact that a singleton is hard to test is one alert that something is not
> right.
>
> Regards,
> Mauricio Aniche
> Master Candidate in Computer Science
> University of São Paulo
> www.aniche.com.br
>
>
> On Thu, Oct 15, 2009 at 7:07 PM, Corey Haines <coreyhaines@...<coreyhaines%40gmail.com>>
> wrote:
>
> >
> >
> > While I am a firm opponent of even thinking about using a singleton, here
> > is
> > a nice video that Brandon Joyce did on TDD-ing a singleton:
> > http://vimeo.com/3182499
> >
> > On Thu, Oct 15, 2009 at 4:00 PM, Adam Sroka <adam.sroka@...<adam.sroka%40gmail.com>
> <adam.sroka%40gmail.com>>
>
> > wrote:
> >
> > >
> > >
> > > On Thu, Oct 15, 2009 at 1:40 PM, Adam Sroka <adam.sroka@...<adam.sroka%40gmail.com>
> <adam.sroka%40gmail.com>
> > <adam.sroka%40gmail.com>>
> > > wrote:
> > > > On Thu, Oct 15, 2009 at 1:19 PM, Nat Pryce <nat.pryce@...<nat.pryce%40gmail.com>
> <nat.pryce%40gmail.com>
> > <nat.pryce%40gmail.com>>
> > > wrote:
> > > >>
> > > >>
> > > >>
> > > >> 2009/10/15 shagil <shagil_t@... <shagil_t%40yahoo.com><shagil_t%
> 40yahoo.com><shagil_t%
>
> > 40yahoo.com>>
> >
> > > >>
> > > >> > Could anyone please suggest how to write a test class for
> Singleton
> > > class?
> > > >>
> > > >> I'd make it not use the Singleton pattern. Instead I'd just create a
> > > >> single instance in the real system and pass it to constructors of
> the
> > > >> objects that need to use it. And create as many throw-away instances
> > > >> in unit tests as necessary.
> > > >>
> > > >
> > > > I agree with Nat. Better to not create a Singleton class, but if you
> > > > want to control instantiation control it above the class. For
> example,
> > > > Spring allows you to annotate a class as being scoped to a Singleton.
> > > > In that model the class is just a regular java class, but Spring
> > > > enforces that it behaves like a Singleton.
> > > >
> > > > I'm not saying that you need to use Spring, necessarily (Or whatever
> > > > the equivalent in your language might be.) However, perhaps another
> > > > class controls instantiation (e.g. a builder or abstract factory) and
> > > > your "singleton" is just a plain-old class.
> > > >
> > > > On the other hand, if you /really/ want to use the Singleton pattern
> > > > as it has been described elsewhere you just need a way to destroy it
> > > > after you have created it. Then you should be able to test it like
> any
> > > > other class. There are a number of ways to do that, the simplest
> being
> > > > to make the default constructor public. Another would be to have the
> > > > factory return a non-final reference that you could nullify. Another
> > > > would be to have an explicit "destroy" method that removes the single
> > > > instance... I'm sure there are others.
> > > >
> > >
> > > P.S. It's also worth considering what your motivation is for creating
> > > a Singleton in the first place. Usually a Singleton is just a way to
> > > store global state, and there is some consensus in the design
> > > community that this is a Bad Thing (Especially in a multi-core,
> > > multi-threaded system.)
> > >
> > >
> >
> > --
> > http://www.coreyhaines.com
> > The Internet's Premiere source of information about Corey Haines
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
>
> [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:
    testdrivendevelopment-digest@...
    testdrivendevelopment-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    testdrivendevelopment-unsubscribe@...

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

[johantoutsimplement]

Another option is to use PowerMock <http://code.google.com/p/powermock/>
. It allows you mock stuff normally not mockable like static, final,
private or constructor methods. Also you can access the internals of a
class.  Powermock is an extension to Mockito or JMock.
Ofcourse you could argue that this is an anti-pattern (it's better to
make the code testable), others would argue that it allows you to not
introduce test-specific methods or change visibility of methods for
purpose of testing.
Johan Martinsson
--- In testdrivendevelopment@..., shagil <shagil_t@...>
wrote:
>
> Hi experts,
>
> Could anyone please suggest how to write a test class for Singleton
class?

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

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

[Adam Sroka-3]

On Thu, Nov 19, 2009 at 4:39 PM, johantoutsimplement
<martinsson.johan@...> wrote:
>
>
>
> Another option is to use PowerMock <http://code.google.com/p/powermock/>
> . It allows you mock stuff normally not mockable like static, final,
> private or constructor methods. Also you can access the internals of a
> class. Powermock is an extension to Mockito or JMock.
> Ofcourse you could argue that this is an anti-pattern (it's better to
> make the code testable),

I would argue that.

others would argue that it allows you to not
> introduce test-specific methods or change visibility of methods for
> purpose of testing.

I agree that that is worse, but it's begging the question.

[nhajratw]

On Nov 19, 2009, at 5:08 PM, Adam Sroka wrote:

> On Thu, Nov 19, 2009 at 4:39 PM, johantoutsimplement
> <martinsson.johan@...> wrote:
> >
> >
> >
> > Another option is to use PowerMock <http://code.google.com/p/powermock/>
> > . It allows you mock stuff normally not mockable like static, final,
> > private or constructor methods. Also you can access the internals of a
> > class. Powermock is an extension to Mockito or JMock.
> > Ofcourse you could argue that this is an anti-pattern (it's better to
> > make the code testable),
>
> I would argue that.
>
>

PowerMock is very good for legacy code bases where there often is not a good/easy/non-destructive way of modifying the code to allow for mocking.

I'd agree that there should be no need for it with new code.

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

[Nuno Marques-4]

I've tried to use powermock and ended up with very bad tests... I'd rather
just build integration tests and refactor code until it's testable.

2009/11/19 Nayan Hajratwala <nayan@...>

>
>
> On Nov 19, 2009, at 5:08 PM, Adam Sroka wrote:
> > On Thu, Nov 19, 2009 at 4:39 PM, johantoutsimplement
> > <martinsson.johan@... <martinsson.johan%40gmail.com>> wrote:
> > >
> > >
> > >
> > > Another option is to use PowerMock <
> http://code.google.com/p/powermock/>
> > > . It allows you mock stuff normally not mockable like static, final,
> > > private or constructor methods. Also you can access the internals of a
> > > class. Powermock is an extension to Mockito or JMock.
> > > Ofcourse you could argue that this is an anti-pattern (it's better to
> > > make the code testable),
> >
> > I would argue that.
> >
> >
> PowerMock is very good for legacy code bases where there often is not a
> good/easy/non-destructive way of modifying the code to allow for mocking.
>
> I'd agree that there should be no need for it with new code.
>
>
> [Non-text portions of this message have been removed]
>
>  
>

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

[Joao E Hornburg]

Just don't use them! They're procedural. Bad OO.

http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/


João E. Hornburg



2009/11/19 twitter.com/nfma <nuno.filipe.marques@...>

>
>
> I've tried to use powermock and ended up with very bad tests... I'd rather
> just build integration tests and refactor code until it's testable.
>
> 2009/11/19 Nayan Hajratwala <nayan@... <nayan%40chikli.com>>
>
>
> >
> >
> > On Nov 19, 2009, at 5:08 PM, Adam Sroka wrote:
> > > On Thu, Nov 19, 2009 at 4:39 PM, johantoutsimplement
> > > <martinsson.johan@... <martinsson.johan%40gmail.com><martinsson.johan%
> 40gmail.com>> wrote:
> > > >
> > > >
> > > >
> > > > Another option is to use PowerMock <
> > http://code.google.com/p/powermock/>
> > > > . It allows you mock stuff normally not mockable like static, final,
> > > > private or constructor methods. Also you can access the internals of
> a
> > > > class. Powermock is an extension to Mockito or JMock.
> > > > Ofcourse you could argue that this is an anti-pattern (it's better to
> > > > make the code testable),
> > >
> > > I would argue that.
> > >
> > >
> > PowerMock is very good for legacy code bases where there often is not a
> > good/easy/non-destructive way of modifying the code to allow for mocking.
> >
> > I'd agree that there should be no need for it with new code.
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
>
> [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:
    testdrivendevelopment-digest@...
    testdrivendevelopment-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    testdrivendevelopment-unsubscribe@...

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

[Charlie Poole-4]

The author specifically says he's talking about a particular
kind of singleton: i.e. one that imposes it's own "singleton-ness."

I agree that this is a bad idea in general, although sometimes
not avoidable.

However, saying that it's bad doesn't go far enough. Various
applications still need "singletons" in the more general sense
of objects that only have a single instance in normal use.

I see a range of badness in singleton usage:

The worst case is where normal object instantiation returns
the same object every time. This is evil, even though it was
a 'standard' pattern in COM. I've also see it done in
C++ where you can redefine what 'new' does.

Implementation as a static is bad, but not as bad as the
first example. In .NET, it's the easiest way to create
an object guaranteed to exist once-and-only-once per
AppDomain. When I have to do this, I will often add a
method for use by tests that clears the static value
and call it in my teardown. It's ugly but can be made
to work and is easy to refactor to a factory.

Use of a factory to provide the object based on a
singleton policy is a very clean approach. You can use
dependency injection to provide the factory and tailor
the policy to provide one object per process, per system,
per AppDomain, etc.  

Since I consider all of these as strategies that permit
use of singletons, I don't see singletons as bad in
themselves. If you're trying to model "there should only
be one xxxx" you need a singleton. It's a question of
how you implement it.

Charlie

> -----Original Message-----
> From: testdrivendevelopment@...
> [mailto:testdrivendevelopment@...] On Behalf Of
> Joao Eduardo Hornburg
> Sent: Thursday, November 19, 2009 8:28 PM
> To: testdrivendevelopment@...
> Subject: Re: [TDD] Re: Test for Singleton class
>
> Just don't use them! They're procedural. Bad OO.
>
> http://misko.hevery.com/code-reviewers-guide/flaw-brittle-glob
> al-state-singletons/
>
>
> João E. Hornburg
>
>
>
> 2009/11/19 twitter.com/nfma <nuno.filipe.marques@...>
>
> >
> >
> > I've tried to use powermock and ended up with very bad tests... I'd
> > rather just build integration tests and refactor code until
> it's testable.
> >
> > 2009/11/19 Nayan Hajratwala <nayan@... <nayan%40chikli.com>>
> >
> >
> > >
> > >
> > > On Nov 19, 2009, at 5:08 PM, Adam Sroka wrote:
> > > > On Thu, Nov 19, 2009 at 4:39 PM, johantoutsimplement
> > > > <martinsson.johan@...
> > > > <martinsson.johan%40gmail.com><martinsson.johan%
> > 40gmail.com>> wrote:
> > > > >
> > > > >
> > > > >
> > > > > Another option is to use PowerMock <
> > > http://code.google.com/p/powermock/>
> > > > > . It allows you mock stuff normally not mockable like static,
> > > > > final, private or constructor methods. Also you can
> access the
> > > > > internals of
> > a
> > > > > class. Powermock is an extension to Mockito or JMock.
> > > > > Ofcourse you could argue that this is an anti-pattern (it's
> > > > > better to make the code testable),
> > > >
> > > > I would argue that.
> > > >
> > > >
> > > PowerMock is very good for legacy code bases where there often is
> > > not a good/easy/non-destructive way of modifying the code
> to allow for mocking.
> > >
> > > I'd agree that there should be no need for it with new code.
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > >
> > >
> >
> > [Non-text portions of this message have been removed]
> >
> >  
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Nuno Marques-4]

There is (I think) an agreement that Singletons and singletons are not the
same thing.
The former are usually considered bad and not the latter...

AFAIU, Shagi was asking about the former...

2009/11/20 Charlie Poole <cpoole@...>

>
>
> The author specifically says he's talking about a particular
> kind of singleton: i.e. one that imposes it's own "singleton-ness."
>
> I agree that this is a bad idea in general, although sometimes
> not avoidable.
>
> However, saying that it's bad doesn't go far enough. Various
> applications still need "singletons" in the more general sense
> of objects that only have a single instance in normal use.
>
> I see a range of badness in singleton usage:
>
> The worst case is where normal object instantiation returns
> the same object every time. This is evil, even though it was
> a 'standard' pattern in COM. I've also see it done in
> C++ where you can redefine what 'new' does.
>
> Implementation as a static is bad, but not as bad as the
> first example. In .NET, it's the easiest way to create
> an object guaranteed to exist once-and-only-once per
> AppDomain. When I have to do this, I will often add a
> method for use by tests that clears the static value
> and call it in my teardown. It's ugly but can be made
> to work and is easy to refactor to a factory.
>
> Use of a factory to provide the object based on a
> singleton policy is a very clean approach. You can use
> dependency injection to provide the factory and tailor
> the policy to provide one object per process, per system,
> per AppDomain, etc.
>
> Since I consider all of these as strategies that permit
> use of singletons, I don't see singletons as bad in
> themselves. If you're trying to model "there should only
> be one xxxx" you need a singleton. It's a question of
> how you implement it.
>
>
> Charlie
>
> > -----Original Message-----
> > From: testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>
> > [mailto:testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>]
> On Behalf Of
> > Joao Eduardo Hornburg
> > Sent: Thursday, November 19, 2009 8:28 PM
> > To: testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>
> > Subject: Re: [TDD] Re: Test for Singleton class
> >
> > Just don't use them! They're procedural. Bad OO.
> >
> > http://misko.hevery.com/code-reviewers-guide/flaw-brittle-glob
> > al-state-singletons/
> >
> >
> > João E. Hornburg
> >
> >
> >
> > 2009/11/19 twitter.com/nfma <nuno.filipe.marques@...<nuno.filipe.marques%40gmail.com>
> >
> >
> > >
> > >
> > > I've tried to use powermock and ended up with very bad tests... I'd
> > > rather just build integration tests and refactor code until
> > it's testable.
> > >
> > > 2009/11/19 Nayan Hajratwala <nayan@... <nayan%40chikli.com><nayan%
> 40chikli.com>>
> > >
> > >
> > > >
> > > >
> > > > On Nov 19, 2009, at 5:08 PM, Adam Sroka wrote:
> > > > > On Thu, Nov 19, 2009 at 4:39 PM, johantoutsimplement
> > > > > <martinsson.johan@... <martinsson.johan%40gmail.com>
> > > > > <martinsson.johan%40gmail.com><martinsson.johan%
> > > 40gmail.com>> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > Another option is to use PowerMock <
> > > > http://code.google.com/p/powermock/>
> > > > > > . It allows you mock stuff normally not mockable like static,
> > > > > > final, private or constructor methods. Also you can
> > access the
> > > > > > internals of
> > > a
> > > > > > class. Powermock is an extension to Mockito or JMock.
> > > > > > Ofcourse you could argue that this is an anti-pattern (it's
> > > > > > better to make the code testable),
> > > > >
> > > > > I would argue that.
> > > > >
> > > > >
> > > > PowerMock is very good for legacy code bases where there often is
> > > > not a good/easy/non-destructive way of modifying the code
> > to allow for mocking.
> > > >
> > > > I'd agree that there should be no need for it with new code.
> > > >
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > > >
> > > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > >
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
>  
>

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

[Kathryn Van Stone]

--- In testdrivendevelopment@..., "Charlie Poole" <cpoole@...> wrote:

>
> The author specifically says he's talking about a particular
> kind of singleton: i.e. one that imposes it's own "singleton-ness."
>
> I agree that this is a bad idea in general, although sometimes
> not avoidable.
>
> However, saying that it's bad doesn't go far enough. Various
> applications still need "singletons" in the more general sense
> of objects that only have a single instance in normal use.
>
> I see a range of badness in singleton usage:
>

...

> Use of a factory to provide the object based on a
> singleton policy is a very clean approach. You can use
> dependency injection to provide the factory and tailor
> the policy to provide one object per process, per system,
> per AppDomain, etc.  
>
> Since I consider all of these as strategies that permit
> use of singletons, I don't see singletons as bad in
> themselves. If you're trying to model "there should only
> be one xxxx" you need a singleton. It's a question of
> how you implement it.
>

I've heard this called the "just use one" version of singleton.  Mostly everyone agrees that this type is okay (when needed); similarly, these are no harder to test than any other object
(assume you create and destroy them in a test fixture).

-Kathy Van Stone
kvs@...

[Adam Sroka-3]

Hi Charlie:

On Fri, Nov 20, 2009 at 8:32 AM, Charlie Poole
<cpoole@...> wrote:
>
> Since I consider all of these as strategies that permit
> use of singletons, I don't see singletons as bad in
> themselves. If you're trying to model "there should only
> be one xxxx" you need a singleton. It's a question of
> how you implement it.
>

The question is why do we care that there is only one? Usually we do
this either to have a single point to coordinate some activity or to
limit the number of object we create when those objects are expensive
(Which is why COM did it, and is also the strategy behind object pools
used in enterprise Java.) These problems can be solved other ways.

Singletons, by definition, require global state. The longer you keep
state in your system the more expensive it is. Global state is kept
for the life of the system. That's potentially bad.

It gets worse when you live in a parallel world, and increasingly all
of our machines do. I'm writing this on a dual-core system. At home I
have an i7 system with Nvidia SLI supporting Cuda. Systems like the
latter are becoming more common and will eventually dominate the
marketplace. Systems like the former already do. Eventually even
cellphones and other embedded devices will all be multicore (Some
already are.) Companies like Google and Amazon have built massive
systems on clusters of machines that they can scale arbitrarily and
farm out jobs to.

Without state massively parallel programs can do many, many operations
in parallel with limited coordination. Global state requires that
every operation be coordinated through a single point (Which is the
stated purpose of the singleton:
http://en.wikipedia.org/wiki/Singleton_pattern) That means that the
part of the system which uses singletons can't be parallel. It becomes
a bottleneck.

My point is this: like I said before you should think really hard
about another way to do things. Singletons are potentially harmful,
and as software becomes increasingly parallel they look more-and-more
like an antipattern.