Re: R: [OT] JNDI datasource lookup to test classes

[James Harman]

Alternatively,

If you are worried about test code in production, you could extend from 
ConnectionHandlerFactory with a TestConnectionHandlerFactor and override 
the getConnectionHandler() method to return the connectionHandler for 
testing. 

James

James CE Johnson wrote:

The most common solution to this problem is using a Factory Method to
return the correct implementation of the interface.  Your classes should
never know which implementation is in use because they will all ask the
Factory Method for the object.  You just need to change the one line in
the method to return a different object for testing.
     

Ok, you mean something like that:

Class ConnectionHandlerFactory
        ...
        public IConnectonHandler getConnectonHandler()
        {
                if (test)
                        return new ConnectionHandlerTest();
                else
                        return new ConnectionHandlerForTomcat();
	}

but I think this has 2 problems:

1) in my production code I'll have code that is written just for testing
purpose
2) Before executing any test I have to set the "test" variable to true.
Or I did not understand?

   

That's the gist of it. We've solved it thusly:

       if (Boolean.getBoolean("use.test.objects")) {
           try {
               return = (IConnectonHandler)
                    Class.forName(
                        "path.to.ConnectionHandlerTest").newInstance();
           } catch (Exception e) {
             log.fatal("Unable to create Test object.", e);
             throw new RuntimeException(e);
           }
       } else {
           return = new ConnectionHandlerForTomcat();
       }
So when we're executing our tests we set the property
use.test.objects=true. It uses Class.forName() to create the object 
instance so that it doesn't have to know about the test object at
compile time or production runtime.

We also keep our testcase source in a separate, though parallel, tree in
the filesystem. That lets us easily build a production jarfile that
doesn't include any of the testcase classes.
(If you need to reach me please email directly as I don't always manage
to keep up with the mailing list.)
Later,
J
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]