Martin,

Can you think of a different implementation where the tests would actually test
different things?
Can you rename the tests so that they discriminate the different cases better?

If they run fast and test different concepts, then I tend towards leaving them.

If not, then I tend towards deleting.

John D.

-----Original Message-----
From: testdrivendevelopment@yahoogroups.com
[mailto:testdrivendevelopment@yahoogroups.com] On Behalf Of Martin Hauner
Sent: 21 November 2009 12:03
To: testdrivendevelopment@yahoogroups.com
Subject: [TDD] Deleting tests?

Hi,

i have tdd'ed a class that filters unmodified directory entries from a previous
directory read. (actually "svn status" against a previous svn "status"). The
idea is to minimize gui updates (a list control containing all items of a
subversion working copy) by just notifying what has really changed since the
last status refresh.

I have created 4 tests, each handling a single update case.

NotifyingViewUpdates.shouldNotifyInsertForNewItems

new list:  A B, old list: empty => notify as new

and similar for the other 3:

NotifyingViewUpdates.shouldNotifyDeleteForObsoleteItems
NotifyingViewUpdates.shouldNotifyUpdateForModifiedItems
NotifyingViewUpdates.shouldNotNotifyIdenticalItems


But by handling each case separately my class couldn't handle mixed input where
it should handle all 4 update types at once. So I wrote another test

NotifyingViewUpdates.shouldNotifyProperNotificationForMixedItems

old list: A B C D E F
new list: C D E' F' G H

with E' & F' being modified versions of E & F.


Now that the last test includes the other 4 tests, should I delete the other
tests or keep them for explanation (which notification is send when)?

I tend toward deleting them considering them mostly as "test noise". What's your
opinion?

--
Martin


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

Yahoo! Groups Links

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.

Hi Martin,

> i have tdd'ed a class that filters unmodified directory
> entries from a previous directory read. (actually "svn
> status" against a previous svn "status"). The idea is to
> minimize gui updates (a list control containing all items of
> a subversion working copy) by just notifying what has really
> changed since the last status refresh.
>
> I have created 4 tests, each handling a single update case.
>
> NotifyingViewUpdates.shouldNotifyInsertForNewItems
>
> new list:  A B, old list: empty => notify as new
>
> and similar for the other 3:
>
> NotifyingViewUpdates.shouldNotifyDeleteForObsoleteItems
> NotifyingViewUpdates.shouldNotifyUpdateForModifiedItems
> NotifyingViewUpdates.shouldNotNotifyIdenticalItems
>
>
> But by handling each case separately my class couldn't handle
> mixed input where it should handle all 4 update types at
> once. So I wrote another test
>
> NotifyingViewUpdates.shouldNotifyProperNotificationForMixedItems
>
> old list: A B C D E F
> new list: C D E' F' G H
>
> with E' & F' being modified versions of E & F.
>
>
> Now that the last test includes the other 4 tests, should I
> delete the other tests or keep them for explanation (which
> notification is send when)?
>
> I tend toward deleting them considering them mostly as "test
> noise". What's your opinion?

If the new test is written so that you can go *directly* to the
offending code when one of the types begins to fail, then delete
the old tests. If not, keep them - or better yet figure out
how to make that happen.

Charlie

Hi,

i have tdd'ed a class that filters unmodified directory entries from a previous
directory read. (actually "svn status" against a previous svn "status"). The
idea is to minimize gui updates (a list control containing all items of a
subversion working copy) by just notifying what has really changed since the
last status refresh.

I have created 4 tests, each handling a single update case.

NotifyingViewUpdates.shouldNotifyInsertForNewItems

new list:  A B, old list: empty => notify as new

and similar for the other 3:

NotifyingViewUpdates.shouldNotifyDeleteForObsoleteItems
NotifyingViewUpdates.shouldNotifyUpdateForModifiedItems
NotifyingViewUpdates.shouldNotNotifyIdenticalItems


But by handling each case separately my class couldn't handle mixed input where
it should handle all 4 update types at once. So I wrote another test

NotifyingViewUpdates.shouldNotifyProperNotificationForMixedItems

old list: A B C D E F
new list: C D E' F' G H

with E' & F' being modified versions of E & F.


Now that the last test includes the other 4 tests, should I delete the other
tests or keep them for explanation (which notification is send when)?

I tend toward deleting them considering them mostly as "test noise". What's your
opinion?

--
Martin

Franz,

Your assumptions are pretty much correct. The interesting part goes on in the
"service handler". And the serializing/deserializing is pretty simple. And I'm
prepared to leave logging out of the equation.

It's actually all working because I test drove it *without* the service layer
(just a MVP wired together). Now, I'm inserting this service layer. The main
problem is that I just read Uncle Bob's "Clean Code". And agreed with most of
what I read. So, now I'm seeing ALL OVER THE PLACE things which are not very
clean! ;-)

I think you propose a good idea: the responsibility of the service method is
just to call the handler. So I'm trying that to see where it leads.

John D.

-----Original Message-----
From: testdrivendevelopment@yahoogroups.com
[mailto:testdrivendevelopment@yahoogroups.com] On Behalf Of Franz Allan Valencia
See
Sent: 20 November 2009 13:19
To: testdrivendevelopment@yahoogroups.com
Subject: Re: [TDD] SRP in a service

By 'Create it in the model layer (which will also store it in the database)
- get an id back', I'm guessing this is where the ServiceHandler delegation
comes in.

From what I can see, they (your ServiceHandler and your actual
CreateTravelPlan service) have different responsibilities. To me, your
CreateTravelPlan service's responsibility is to delegate to ServiceHandler
with the translation to and from the ServiceHandler.That to me is just a
single responsibility (That is assuming the deserialization and wrapping of
id in a response string is pretty straight forward. If they have logic of
their own, then you can consider moving them to another method/class ).

While your ServiceHandler handles the actual business logic. I'm guessing
this is where you will have your 'interesting' tests :-)

As for the logging, I usually don't test those. That is unless it is
essential to the whole process. If it is, then you should test if it really
did log :-)

Cheers,

--
Franz Allan Valencia See | Java Software Engineer
franz.see@...
LinkedIn: http://www.linkedin.com/in/franzsee
Twitter: http://www.twitter.com/franz_see


On Fri, Nov 20, 2009 at 7:19 PM, Donaldson, John (GEO) <
john.m.donaldson@...> wrote:

>
>
> I'm having some difficulty with SRP in the context of a SOA service. For
> the sake of the discussion, let's say we have a service "CreateTravelPlan"
> which takes a travel plan in some kind of serialized form (as a string). It
> has to return an id of the created travel plan (also serialized into a
> string). It could have a signature like this:
>
> - String CreateTravelPlan( string thePlan)
>
> This service method has to:
>
> - Log some stuff
>
> - Deserialize the incoming plan
>
> - Create it in the model layer (which will also store it in the database) -
> get an id back
>
> - Wrap the id in a response string
>
> - Return the response
>
> Because it's difficult to unit test in a service context, I'll have a
> "humble service" - I'll just delegate out to a ServiceHandler (or some
> better name). I'll have to inject: the Logger, the Deserializer, the
> TravelPlanSaver, the ResponseCreator! (Yikes already).
>
> The problem is that ServiceHandler will have to do the things I listed
> above. So, how to move closer to a "single responsibility" situation?
> I feel like I'm making some fundamental mistake - but I don't see it.
>
> John D.
>
> [Non-text portions of this message have been removed]
>
>
>


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



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

Yahoo! Groups Links

--- In testdrivendevelopment@yahoogroups.com, "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@...

Hi Michael,

The feature/construct distinction is a good insight!

Charlie

> -----Original Message-----
> From: testdrivendevelopment@yahoogroups.com
> [mailto:testdrivendevelopment@yahoogroups.com] On Behalf Of
> mfeathers256
> Sent: Thursday, November 19, 2009 10:52 PM
> To: testdrivendevelopment@yahoogroups.com
> Subject: [TDD] ANN: Testable Java
>
>
> I just wrote a paper called 'Testable Java' which outlines
> the sort of testability traps that I see people fall into
> over and over again when they aren't doing TDD.  It also
> presents a simple rule teams can use to avoid them.
>
> http://www.objectmentor.com/resources/articles/TestableJava.pdf
>
> All feedback welcome,
>
> Michael
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

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@yahoogroups.com
> [mailto:testdrivendevelopment@yahoogroups.com] On Behalf Of
> Joao Eduardo Hornburg
> Sent: Thursday, November 19, 2009 8:28 PM
> To: testdrivendevelopment@yahoogroups.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@...>
>
> >
> >
> > 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
>
>
>
>

By 'Create it in the model layer (which will also store it in the database)
- get an id back', I'm guessing this is where the ServiceHandler delegation
comes in.

From what I can see, they (your ServiceHandler and your actual
CreateTravelPlan service) have different responsibilities. To me, your
CreateTravelPlan service's responsibility is to delegate to ServiceHandler
with the translation to and from the ServiceHandler.That to me is just a
single responsibility (That is assuming the deserialization and wrapping of
id in a response string is pretty straight forward. If they have logic of
their own, then you can consider moving them to another method/class ).

While your ServiceHandler handles the actual business logic. I'm guessing
this is where you will have your 'interesting' tests :-)

As for the logging, I usually don't test those. That is unless it is
essential to the whole process. If it is, then you should test if it really
did log :-)

Cheers,

--
Franz Allan Valencia See | Java Software Engineer
franz.see@...
LinkedIn: http://www.linkedin.com/in/franzsee
Twitter: http://www.twitter.com/franz_see


On Fri, Nov 20, 2009 at 7:19 PM, Donaldson, John (GEO) <
john.m.donaldson@...> wrote:

>
>
> I'm having some difficulty with SRP in the context of a SOA service. For
> the sake of the discussion, let's say we have a service "CreateTravelPlan"
> which takes a travel plan in some kind of serialized form (as a string). It
> has to return an id of the created travel plan (also serialized into a
> string). It could have a signature like this:
>
> - String CreateTravelPlan( string thePlan)
>
> This service method has to:
>
> - Log some stuff
>
> - Deserialize the incoming plan
>
> - Create it in the model layer (which will also store it in the database) -
> get an id back
>
> - Wrap the id in a response string
>
> - Return the response
>
> Because it's difficult to unit test in a service context, I'll have a
> "humble service" - I'll just delegate out to a ServiceHandler (or some
> better name). I'll have to inject: the Logger, the Deserializer, the
> TravelPlanSaver, the ResponseCreator! (Yikes already).
>
> The problem is that ServiceHandler will have to do the things I listed
> above. So, how to move closer to a "single responsibility" situation?
> I feel like I'm making some fundamental mistake - but I don't see it.
>
> John D.
>
> [Non-text portions of this message have been removed]
>
>
>


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

To be honest, I am not very fond of those objects serialized into strings -
deserializing and serializing should be infrastructural concerns that has
nothing to do with your logic, and are cross cutting concerns. So does
logging. Those could be abstracted out with AOP (injecting logger and some
[Service] attribute may be, like [OperationContract] in WCF).

This leaves you only with your DAO - or Domain model aggregate root, or
ITravelPlanSaver whatever. Your service is just an orchestrator so it is
normal for that to be this thin.

On Fri, Nov 20, 2009 at 12:19 PM, Donaldson, John (GEO) <
john.m.donaldson@...> wrote:

>
>
> I'm having some difficulty with SRP in the context of a SOA service. For
> the sake of the discussion, let's say we have a service "CreateTravelPlan"
> which takes a travel plan in some kind of serialized form (as a string). It
> has to return an id of the created travel plan (also serialized into a
> string). It could have a signature like this:
>
> - String CreateTravelPlan( string thePlan)
>
> This service method has to:
>
> - Log some stuff
>
> - Deserialize the incoming plan
>
> - Create it in the model layer (which will also store it in the database) -
> get an id back
>
> - Wrap the id in a response string
>
> - Return the response
>
> Because it's difficult to unit test in a service context, I'll have a
> "humble service" - I'll just delegate out to a ServiceHandler (or some
> better name). I'll have to inject: the Logger, the Deserializer, the
> TravelPlanSaver, the ResponseCreator! (Yikes already).
>
> The problem is that ServiceHandler will have to do the things I listed
> above. So, how to move closer to a "single responsibility" situation?
> I feel like I'm making some fundamental mistake - but I don't see it.
>
> John D.
>
> [Non-text portions of this message have been removed]
>
>
>



--
Sidar Ok

http://www.sidarok.com
http://www.twitter.com/sidarok


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

I'm having some difficulty with SRP in the context of a SOA service. For the
sake of the discussion, let's say we have a service "CreateTravelPlan" which
takes a travel plan in some kind of serialized form (as a string). It has to
return an id of the created travel plan (also serialized into a string). It
could have a signature like this:


-          String CreateTravelPlan( string thePlan)

This service method has to:

-          Log some stuff

-          Deserialize the incoming plan

-          Create it in the model layer (which will also store it in the
database) - get an id back

-          Wrap the id in a response string

-          Return the response

Because it's difficult to unit test in a service context, I'll have a "humble
service" - I'll just delegate out to a ServiceHandler (or some better name).
I'll have to inject: the Logger, the Deserializer, the TravelPlanSaver, the
ResponseCreator! (Yikes already).

The problem is that ServiceHandler will have to do the things I listed above.
So, how to move closer to a "single responsibility" situation?
I feel like I'm making some fundamental mistake - but I don't see it.

John D.



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

Timely, enlightening and concise. Thank you sir for taking the time to bring
this piece to the general populace.

Now I have a checklist of usual-suspects to point the hordes of developers
to, who complain about how TDD is impossible for their specific hand-crafted
situation.

-- Gishu

Things that brought a knowing smile to my face as I read them:

** "Code that wasn’t designed to be
testable is not testable. Testability is not a quality that appears
accidently."
A recurring image that I have is developers tying (tests) balloons to make a
giant "untestable by-the-seat-of-my-pants" ship of code fly - without seeing
the multiple anchors (no attention paid to testability in the first place,
TUFs galore, etc.) that are rendering all their efforts moot

** "TDD is a high-discipline approach"
I am prepared to wear this T-Shirt everyday.

** Strictly speaking, final classes and final methods are only a problem in
testing when they hide a TUF, but it is nice to have a carefully considered
reason for using them rather than just using them by default.
Pragmatic. .Net design guidelines dictate making classes non-inheritable by
default (for framework / library classes). Glad to see that you're not
advocating a blanket ban on final

*** Really liked the name of the configuration file. Conveys Intent :)

*** constructors are TUCs.


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

I just wrote a paper called 'Testable Java' which outlines the sort of
testability traps that I see people fall into over and over again when they
aren't doing TDD.  It also presents a simple rule teams can use to avoid them.

http://www.objectmentor.com/resources/articles/TestableJava.pdf

All feedback welcome,

Michael

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

http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singleton\
s/


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]

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]

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]

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.

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@yahoogroups.com, 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]

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]

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]

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
+972-524-655388 (GMT+2)


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

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. :)

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]

Hi Lior,

I really enjoyed your response to Roy's post. I don't agree that
TypeMock is evil, will cause bad design, or will injure innocent
kittens. However I also disagree that the feedback given by
proxy-based mocking tools is useless. I feel the tool limitations Roy
mentions in this case are more limitations of the languages they proxy
over, and as such they end up providing feedback when your design
won't change easily using your language/framework of choice.

Some people like this feedback, others don't want it and/or don't need
it. In the end it comes down to personal preference -- good design
will depend on the individual, not the tools.

If you'd like to read my full response you can stop by my blog:
http://www.davesquared.net/2009/11/impact-of-mocking-framework-limitations.html

Regards,
David

On Mon, Nov 16, 2009 at 6:56 PM, Lior Friedman <lfriedmal@...> wrote:
>
>
>
> Here's one for you:
>
> http://weblogs.asp.net/rosherove/archive/2009/11/12/test-driven-design-wille
> d-vs-forced-designs.aspx
>
> I brought it here because no matter where you stand the discussion is always
> worthwhile in my opinion
>
> Lior Friedman
> Blog - <http://imistaken.blogspot.com/> http://imistaken.blogspot.com
>
> [Non-text portions of this message have been removed]
>
>

js_runit <http://github.com/gutzofter/js_runit>  is now a standalone
JavaScript testing framework. So if your into a minimalist JavaScript
testing experience, this tool is for you. Two files to download. The
html file and the JavaScript file. Included with this is an example of
Passive View with unit tests.

To really appreciate this see the passive view example
<http://jsbin.com/ebuce/edit> .

The unit tests for the above example can be found here
<http://jsbin.com/uhiza/edit> .

Happy unit testing.



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

2009/11/10 Steve Freeman <smgfreeman@...>

>
>
> We cover some of these situations in our book.
>
>
> On 23 Oct 2009, at 18:45, Dale Emery wrote:
> >
> > My guess is this: The UUT calls two kinds of methods on its
> collaborators:
> > queries and actions (e.g. commands, notifications, ...). I'm sure there's
> a
> > better word than "action" here, but I can't think of it.
>
> > In general, I don't test query calls directly, because I don't think of
> the
> > [...]
>
> > when(), and don't worry about strictness for those.
>
> Agreed. We have a heuristic, "Stub Queries, Mock Actions"
>

Great sentence Steve. I use it in my Spanish TDD book-in-progress  (credits
to you are in the book of course)


>
> > Under what conditions would the UUT have a definite responsibility /not/
> to
> > call some method? There are protocols with that kind of responsibility. I
> > can't think of a good example at the moment, so I'll offer a lame one:
> > Disallow invoking some action until the user has logged in. Mockito's
> > verifyNoMoreInteractions() can handle that.
>
> I want to know later, when I've changed some other part of the code, that
> I've not triggered an unexpected action on a collaborator.
>
> > I can't think of a time when I wanted to verify that the UUT refrained
> from
> > calling a /particular/ method, though I can imagine protocols with that
> > responsibility.
>
> Sometimes I write a never() clause into the test to show the reader what my
> intentions are: in /this/ case it happens, in /that/ case I'm doing
> something else. It's not necessary computationally, but is a means of
> expression.
>
>
> > If I remember right (it's been about a year since I used mockito),
> mockito
> > also does not verify the order in which calls were made. I can't recall
> > having a need for that, though, again, I can imagine protocols with that
> > responsibility.
>
> it's not impossible. Consider sending a message before closing a
> connection. In our worked example, we implement a state machine, so we want
> to show that some transitions happen in the right order.
>

You might need a strict mock for performance reasons too: say you need to
ensure that the SUT hits the remote service just once in the whole process.
Haven't try mockito yet (by the way the name is terrible in Spanish: little
snot) but I appreciate Rhino.Mocks' features: GenerateMock and
GenerateStrictMock. With the methods others have said here, I get the
feeling mockit offers pretty much the same capabilities.

Thanks Gojko



>
> S.
>
> Steve Freeman
> http://www.mockobjects.com
> http://www.growing-object-oriented-software.com
>
> Winner of the Agile Alliance Gordon Pask award 2006
>
>
>



--
Carlos Ble
www.iExpertos.com
www.carlosble.com


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

[PLUG] In this blog post, I try to address the problem of managing several
tests using Gerard Meszaros' Test Organization (plus a bit of BDD).

http://franz-see.blogspot.com/2009/10/test-organizations.html

Cheers,
--
Franz Allan Valencia See | Java Software Engineer
franz.see@...
LinkedIn: http://www.linkedin.com/in/franzsee
Twitter: http://www.twitter.com/franz_see


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

Here's one for you:

http://weblogs.asp.net/rosherove/archive/2009/11/12/test-driven-design-wille
d-vs-forced-designs.aspx



I brought it here because no matter where you stand the discussion is always
worthwhile in my opinion





Lior Friedman
Blog  -  <http://imistaken.blogspot.com/> http://imistaken.blogspot.com







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

This has been about how to help people *adopt* TDD from the beginning, not about
TDD itself.
The start point was that I wanted to have everybody on the team tried TDD at
least twice before adopting or rejecting it. The developer in question rejected
it before having tried it even once.

Her work was and is OK, complete with unit tests and all, only her code is not
very modular and she doesn't have the reflexes that come naturally when you TDD
your code. It's more like she modifies her code later in order to be able to
test it. This is waste in my opinion.
Another aspect is, that for a team that is in the process of adopting a new
technique it is disturbing to hear someone always say how she cannot see the use
of that technique, how it isn't applicable to the code she is writing right now
and so on.

But I think she will go at least through the "try it twice" phase (she starts to
be a bit less opposed by now); if she rejects it after that is OK for me. I
would still hope that team dynamics will do the trick in the end, though.

If you are interested, I will post the outcome here, let's say at the end of the
year.

Thanks for all your help!
Martin

--- In testdrivendevelopment@yahoogroups.com, Mike Emeigh <mwe55innc@...> wrote:
>
> On Tue, Nov 10, 2009 at 12:10 PM, Steve Freeman wrote:
> >
> >
> >
> > This is beginning to sound as if it's not really about TDD.
> >
> > Perhaps it's about her view of herself as an expert coder, or her autonomy
over how she does her work? What does she see that
> > the others don't? Does she not respect the opinions of her team? Is she
feeling frustrated because she can't get stuff done with
> > TDD, and just wants to get on and write code? -- and what does that say
about the delivery culture? Does she not agree with the
> > benefits that you (and the others?) perceive?
>
> Other questions: Are there any issues with the quality of her
> delivered code and/or tests? If there are not, then why does your team
> want her to use a method with which she is (for whatever reason)
> uncomfortable? As long as she is delivering working software (and
> tests along with it, which it sounds as though she is), why does it
> matter to your team what method she is using to deliver that working
> software and tests?
>
> Now if she's NOT delivering working software and tests in a timely
> manner - as your team defines working software and tests, that is -
> then the team needs to take a harder look at what she is doing. If she
> IS delivering working software and tests but in a way that causes
> unnecessary friction within the team, then the team needs to take a
> look at that as well. But if she's delivering the product that the
> team needs from her when the team needs it, I personally wouldn't get
> too hung up over the specific method by which it's created.
> --
> Mike Emeigh
> MWE55inNC@...
>
> "Our brains, for all their wonders, identify the following four things
> as being very bad for survival: Standing alone, in open territory with
> no place to hide, without a weapon, in front of a large crowd of
> creatures staring at you"
>
> -- Scott Berkun, about why people fear public speaking
>

> Thanks, I should probably re-read it. I had high expectations, but
> ultimately didn't find it very useful.

First time i read this book several years ago, i found it a bit dry and
didnt understand what all the fuss was about. After hearing comments
<http://news.squeak.org/2007/02/06/oo-programmers-fall-into-two-categori\
es-smalltalkers-and-those-who-dont-get-it/>  like "  “OO
programmers fall into two categories: Smalltalkers and those who
don’t get it.�  I used a lot of my spare time learning
smalltalk  <http://www.pharo-project.org/home>  and reading
http://www.wirfs-brock.com/Resources.html,
http://www.macqueen.us/stIndex.html. I have since re-read/studied
"Object Design: Roles, Responsibilities and Collaborations" couple of
times and I appreciate it alot more, and learnt a whole bunch more. That
was my personal journey to 're-learning' OO concepts,  I would definetly
encourage to re-read/study  it, i'm sure if I read it again there would
be something more i would learn.

I then began to understand other ideas like using mock objects, Tdd, to
guide the design of OO


--- In testdrivendevelopment@yahoogroups.com, Kim Gr�sman
<kim.grasman@...> wrote:
>
> Steve,
>
> On Tue, Nov 10, 2009 at 22:36, Steve Freeman smgfreeman@... wrote:
> > On 11 Sep 2009, at 16:52, Kim Gr�sman wrote:
> >> Thanks -- I'm mostly in C++ and sometimes .NET, I guess I was
looking
> >> for more general OO design reading. Currently trying to get through
> >> "Object Design: Roles, Responsibilities and Collaborations", but
not
> >> really seeing the light.
> >
> > Spend some quality time with that book. Then a lot of other ideas
will
> > make more sense.
>
> Thanks, I should probably re-read it. I had high expectations, but
> ultimately didn't find it very useful. Likely a problem with the
> reader and not the publication :)
>
> Cheers,
> - Kim
>



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