article on singleton and unit testing

Discussion in 'Java' started by Jean Lutrin, May 2, 2004.

  1. Jean Lutrin

    Jean Lutrin 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 ?

    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
    Jean Lutrin, May 2, 2004
    #1
    1. Advertising

  2. Jean Lutrin

    Roedy Green Guest

    On 1 May 2004 21:18:06 -0700, (Jean Lutrin) wrote
    or quoted :

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



    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, May 2, 2004
    #2
    1. Advertising

  3. Jean Lutrin

    Guest

    On 1 May 2004 21:18:06 -0700, (Jean Lutrin) wrote:

    >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
    , May 2, 2004
    #3
  4. Jean Lutrin

    Filip Larsen Guest

    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,
    --
    Filip Larsen
    Filip Larsen, May 2, 2004
    #4
  5. Jean Lutrin

    Jean Lutrin Guest

    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".
    Jean Lutrin, May 2, 2004
    #5
  6. 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


    <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
    John C. Bollinger, May 3, 2004
    #6
  7. Jean Lutrin

    Dave Monroe Guest

    "John C. Bollinger" <> wrote in message
    > 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.
    Dave Monroe, May 5, 2004
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Maclean
    Replies:
    1
    Views:
    337
    Martin P. Hellwig
    Apr 13, 2010
  2. Tori
    Replies:
    1
    Views:
    464
  3. Ulrich Eckhardt

    unit-profiling, similar to unit-testing

    Ulrich Eckhardt, Nov 16, 2011, in forum: Python
    Replies:
    6
    Views:
    325
    Roy Smith
    Nov 18, 2011
  4. Bill Mosteller
    Replies:
    0
    Views:
    218
    Bill Mosteller
    Oct 22, 2009
  5. James Harris

    C unit testing and regression testing

    James Harris, Aug 8, 2013, in forum: C Programming
    Replies:
    40
    Views:
    589
    Les Cargill
    Aug 17, 2013
Loading...

Share This Page