article on singleton and unit testing

[Jean Lutrin]

Hi all,

I have a question regarding an article written some
time ago by someone at IBM (in 2001), called
"Use your singletons wisely". Here's the article :

http://www-106.ibm.com/developerworks/webservices/library/co-single.html

Only people who already read that article or willing
to read it will be able to follow what's coming now

My question is not about the singleton, but about
an example that I really don't get.

At one point, after a sample unit test, the author writes :

"You may wonder why you shouldn't just specify a silly
file name to actually create the exception condition,
rather than simulate it. We're interested only in
simulating the exception condition, and not re-creating
it -- doing the latter more easily leads to confusion."

It was *exactly* what I was thinking when reading is example
source code.

I use unit testing (and code coverage tools btw) quite often
and I am completely puzzled by his example.

Basically, he adds a "fake" method to a MockDeployer called
doNotFindAnyFiles() instead of using a deliberately
non-existing filename, because he argues, rightly, that the
file, whatever crazy the name, could exists (this is debatable
btw, on an OS with file access permission -- Windows 2000, XP,
Linux, Solaris, whatever Un*x for what it is worth, -- it is
actually trivial to choose a filename that you'll be sure
won't able to be written).

But then what is his unit test testing ? The unit test is
suppose to test the correct behavior of the Deployer class
in the case where some file could not be written ?

Instead, as I understand the example, he is testing that the
"fake" method (which has no purpose other than pass the unit
test) called doNotFindAnyFiles() in his MockDeployer his
acting correctly ?

So in his MockDeployerClass he adds a test somewhere
which probably ressembles something like, say :

if (doNotFindAnyFilesFlag == true)
{
throw new FileNotFoundException(...)
}


How is that helping at all testing the "real" Deployer ?

As I see it, this is just adding unnecessary kludge to the
project : unnecessary unit tests (not testing the right
thing) and unnecessary methods in the MockDeployer (the method
doNotFindAnyFiles() as no purpose in the real Deployer) ?

But then I am surely completely wrong.

Please, help me, there's something that I really didn't
get in this paper (btw I did like the paper : but I have
this strange feeling that I didn't really understand
anything because of this example that I don't get).

Thanks in advance,

Jean

 

[Roedy Green]

if (doNotFindAnyFilesFlag == true)
{
throw new FileNotFoundException(...)
}

doNotFindAnyFiles is already a boolean, you don't need to convert it
to one.

try simply

if (doNotFindAnyFilesFlag)

This is equivalent is English to saying

"If it is true that Bush lied about WMDs" instead of saying simply
"If Bush lied about WMDs"....

It is a sort of stuttering.

Imagine someone who carried this even further

If it is true that it is true that Bush lied about WMDs".

That's how that locution sounds to me.

 

[Guest]

Hi all,

I have a question regarding an article written some
time ago by someone at IBM (in 2001), called
"Use your singletons wisely". Here's the article :

http://www-106.ibm.com/developerworks/webservices/library/co-single.html

Only people who already read that article or willing
to read it will be able to follow what's coming now

My question is not about the singleton, but about
an example that I really don't get.

At one point, after a sample unit test, the author writes :

"You may wonder why you shouldn't just specify a silly
file name to actually create the exception condition,
rather than simulate it. We're interested only in
simulating the exception condition, and not re-creating
it -- doing the latter more easily leads to confusion."

It was *exactly* what I was thinking when reading is example
source code.

I use unit testing (and code coverage tools btw) quite often
and I am completely puzzled by his example.

Basically, he adds a "fake" method to a MockDeployer called
doNotFindAnyFiles() instead of using a deliberately
non-existing filename, because he argues, rightly, that the
file, whatever crazy the name, could exists (this is debatable
btw, on an OS with file access permission -- Windows 2000, XP,
Linux, Solaris, whatever Un*x for what it is worth, -- it is
actually trivial to choose a filename that you'll be sure
won't able to be written).

But then what is his unit test testing ? The unit test is
suppose to test the correct behavior of the Deployer class
in the case where some file could not be written ?

Instead, as I understand the example, he is testing that the
"fake" method (which has no purpose other than pass the unit
test) called doNotFindAnyFiles() in his MockDeployer his
acting correctly ?

So in his MockDeployerClass he adds a test somewhere
which probably ressembles something like, say :

if (doNotFindAnyFilesFlag == true)
{
throw new FileNotFoundException(...)
}


How is that helping at all testing the "real" Deployer ?

Perhaps you are confused between Deployer and Deployment.
Deployment has a dependency on Deployer. We want to test
Deployment (specifically deploy()), not Deployer. In the
case where the deployment file cannot be found, deploy()
(in Deployment) is apparently supposed to throw a
FileNotFoundException. To simulate this you simply create
a MockDeployer (note *Deployer*) such that it always throws this
exception.

The example may have been easier to understand had it not been
so trivial (Deployment's deploy() simply delegates to Deployer's
deploy()).

Pete

 

[Filip Larsen]

Jean Lutrin wrote

I have a question regarding an article written some
time ago by someone at IBM (in 2001), called
"Use your singletons wisely". Here's the article :

http://www-106.ibm.com/developerworks/webservices/library/co-single.html

Only people who already read that article or willing
to read it will be able to follow what's coming now

I haven't read the article so the following comment may not be relevant.

Instead, as I understand the example, he is testing that the
"fake" method (which has no purpose other than pass the unit
test) called doNotFindAnyFiles() in his MockDeployer his
acting correctly ?

How is that helping at all testing the "real" Deployer ?

To me it sounds like he uses the "drivers and stubs" test pattern (don't
know if anyone has actually described that pattern). Drivers corresponds
to the JUnit code, they drive the test and the classes under test, and
stubs are test classes build to give a "controlled test environment" for
the class to be unit tested to be in.

Lets say you want to test class A, which is an implementation of API
"A", and that class A uses another API, say API "B". In order to unit
test class A you would have to test the class under the assumption that
the implementation of API "B" is correct so that any bugs, limitations,
or other quirks of a real API "B" production implementation do not creep
into the unit test of class A. To do this you typically write a test
stub implementing API "B" so that you can properly test that class A can
hold API "A" under the full variation possible in API "B". Separate from
this, you can then test that any production implementation of API "B"
actually are adhering to the API as you thought. If API "B" is defined
by you, then that test would correspond to a unit test of some class B.
If API "B" is a library or system service then you can make a test that
the assumptions you have about API "B" is correct for those
implementations (like if a file is not found a FileNotFoundException is
indeed thrown in this and that case).

Note that if you try to unit test class A using a production
implementation of API "B", you are really mixing unit test of class A
with integration testing of class A and B, and in this mix you risk that
you cannot fully unit test A if you do not have full control of the
behaviour of class B.


If the above is not relevant for your question, I apologize.

Regards,

 

[Jean Lutrin]

Thanks for your answer.

The example was indeed so "simple" that I could not
get the big picture. After reading both of your posts,
I went re-reading it carefully and now I understand
what the author is doing exactly (I was not cautious
enough to spot the difference between Deployer and
Deployment in the example, and kept focusing on the
wrong paragraph !).



Thanks again and see you one of those days on cljp,

Jean


P.S : I'm forced to use groups.google.com to post
my messages to Usenet... I hope this message won't
get "top-posted".

 

[John C. Bollinger]

I have a question regarding an article written some
time ago by someone at IBM (in 2001), called
"Use your singletons wisely". Here's the article :

http://www-106.ibm.com/developerworks/webservices/library/co-single.html

<stand where="soapbox">
Your question was already aptly answered, but I wanted to offer my
thanks for pointing out the article. It makes some nice arguments in
support of my own position on use of singletons, which is "only use them
where you must." I see too many designs and too much code that use
singletons apparently just because [the designer thinks] they can. I
even once saw a design including an _abstract_ "singleton" with multiple
subclasses. Yuck.

I think too many programmers focus on design patterns as an end rather
than a means, and approach design with an attitude of trying to find
places to apply patterns. (As if that will automatically lead to good
designs.) "Singleton" is an easy concept to grasp, and it has a
single-class implementation; that makes it low-hanging fruit for such a
designer.
</stand>


John Bollinger
(e-mail address removed)

 

[Dave Monroe]

I think too many programmers focus on design patterns as an end rather
than a means, and approach design with an attitude of trying to find
places to apply patterns. (As if that will automatically lead to good
designs.) "Singleton" is an easy concept to grasp, and it has a
single-class implementation; that makes it low-hanging fruit for such a
designer.

If you're talking about experienced developers, you have a point.

I've seen situations where Java was mandated on a group of developers
used to doing work on legacy systems. It seems that 'new' is easier
to grasp than 'singleton'.

The garbage collector pays the price.