[jira] [Created] (OODT-626) Unit tests for TestDeleteProductByName and TestDeleteProductById don't override all needed methods in getClient

["Chris A. Mattmann (JIRA)" <ji...@apache.org>]

Chris A. Mattmann created OODT-626:
--------------------------------------

             Summary: Unit tests for TestDeleteProductByName and TestDeleteProductById don't override all needed methods in getClient
                 Key: OODT-626
                 URL: https://issues.apache.org/jira/browse/OODT-626
             Project: OODT
          Issue Type: Bug
          Components: file manager
         Environment: Mac OS X 10.8.3
[chipotle:oodt/trunk/filemgr] mattmann% java -version
java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b06-451-11M4406)
Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01-451, mixed mode)
[chipotle:oodt/trunk/filemgr] mattmann% 

            Reporter: Chris A. Mattmann
             Fix For: 0.6


While investigating a possible policy bug, I ran into the issue with the following two hanging action tests:

* TestDeleteProductByIdAction
* TestDeleteProductByNameAction

Take the first action test, TestDeleteProductByIdAction. While investigating, I found that it hangs in this method on line 75 where it is creating a mock object FalseDeleteProductByNameCliAction. 

{code:java}
      cliAction = new FalseDeleteProductByNameCliAction();
      cliAction.setProductName(PRODUCT_NAME);
      try {
         cliAction.execute(printer);
         fail("Expected throw CmdLineActionException");
      } catch (CmdLineActionException ignore) {
      }
{code}

The actual line it hangs in is in cliAction.execute. Looking in that line it seems to hang because in AbstractDeleteProductionAction, line 50, due to this code block:

{code:java}
         for (Reference ref : refs) {
            if (!client.removeFile(new File(new URI(ref.getDataStoreReference()))
                  .getAbsolutePath())) {
               throw new Exception("Failed to delete file '"
                     + ref.getDataStoreReference() + "'");
            }
         }
{code}

Basically it seems that TestGetDeleteProductByIdAction and its subclass FalseDeleteProductByNameCliAction do not define the method, removeFile, which in turn is called by the above code. The only problem is that version of that function that is called is the XmlRpcFileManagerClient#removeFile, which actually tries to make an XmlRpc connection. Because of the code here:

{code:java}
                CommonsXmlRpcTransport transport = new CommonsXmlRpcTransport(
                        url, client);
                transport
                        .setConnectionTimeout(Integer
                                .getInteger(
                                        "org.apache.oodt.cas.filemgr.system.xmlrpc.connectionTimeout.minutes",
                                        20).intValue() * 60 * 1000);
                transport
                        .setTimeout(Integer
                                .getInteger(
                                        "org.apache.oodt.cas.filemgr.system.xmlrpc.requestTimeout.minutes",
                                        60).intValue() * 60 * 1000);
{code}

it seems like this test should hang forever, and time out (or at least for 60 minutes). However, we don't notice this...on tests that run on our own Jenkins server:

https://builds.apache.org/job/oodt-trunk/964/org.apache.oodt$cas-filemgr/console

Or on some of our dev computers (e.g., Andrew Hart's ubtuntu VM). 
Also I don't remember this failing over the past year too much and this code has existed for well over this time. So, I'm stumped. In the interest of helping anyone else that has this problem I attach a patch that fixes these 2 tests by adding local override implementations of the methods removeFile and others required to intercept the calls and to stay away from XML-RPC calls.

Brian Foster or anyone else it would be great if you can comment here.






--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira