Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tm-dev] renabling JUnits?

Hi Martin,

Thanks for letting me know where the junits stand.

____________________________________
David McKnight    
Phone:   905-413-3902 , T/L:  969-3902
Internet: dmcknigh@xxxxxxxxxx
Mail:       D1/YFY/8200/TOR
____________________________________



Inactive hide details for "Oberhuber, Martin" ---22/01/2013 04:18:21 PM---Hi Dave, We never tested against any actual hosts in "Oberhuber, Martin" ---22/01/2013 04:18:21 PM---Hi Dave, We never tested against any actual hosts in our Junit tests.


    From:

"Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>

    To:

TM project developer discussions <tm-dev@xxxxxxxxxxx>

    Cc:

"tm-dev-bounces@xxxxxxxxxxx" <tm-dev-bounces@xxxxxxxxxxx>

    Date:

22/01/2013 04:18 PM

    Subject:

Re: [tm-dev] renabling JUnits?

    Sent by:

tm-dev-bounces@xxxxxxxxxxx




Hi Dave,
 
We never tested against any actual hosts in our Junit tests.
 
Those commented-out lines for testing against other hosts had only been run locally by individual developers (like myself).
So the code for patching the .properties files and/or finding another way for accessing remote hosts during the Junits is still TBD.
 
I still think that testing “plain EFS” local against “RSE EFS” local does have some value.
Adding ssh to the mix should be fairly easy when using a .ssh folder allowing login to a different host at Eclipse.org .
Dstore might also be possible when asking webmaster for a server on which a dstore daemon can run.
 
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6
 
    From: tm-dev-bounces@xxxxxxxxxxx [mailto:tm-dev-bounces@xxxxxxxxxxx] On Behalf Of David McKnight
    Sent:
     Tuesday, January 22, 2013 5:02 PM
    To:
     TM project developer discussions
    Cc:
     TM project developer discussions; tm-dev-bounces@xxxxxxxxxxx
    Subject:
     Re: [tm-dev] renabling JUnits?
     

    Thanks for responding, Martin.

    I'll add my comments in
    green. 

    ____________________________________
    David McKnight    
    Phone:   905-413-3902 , T/L:  969-3902
    Internet:
    dmcknigh@xxxxxxxxxx
    Mail:       D1/YFY/8200/TOR
    ____________________________________



    Inactive hide details for "Oberhuber, Martin" ---22/01/2013 02:41:16 AM---Hi all, Comments inline below:"Oberhuber, Martin" ---22/01/2013 02:41:16 AM---Hi all, Comments inline below:

      From:
      To:
      Date:

      22/01/2013 02:41 AM
      Subject:

      Re: [tm-dev] renabling JUnits?
      Sent by:





    Hi all,

    Comments inline below:
     

      First, the ScpFileSubsystemTestCase.testScpAccessToRemoteHost() is failing because the "userid" in scpConnection.properties is set to "unknown" and RSEConnectionManager.findOrCreateConnection() does the following test:

      String userId = properties.getProperty(IRSEConnectionProperties.ATTR_USERID);
      Assert.assertFalse("FAILED(findOrCreateConnection): Invalid user id name!",
       "unknown".equals(userId)); //$NON-NLS-1$ //$NON-NLS-2$

      Is this "userid" supposed to be set in the scpConnection.properties?

    Correct, the idea of those tests was that the .properties files are patched with an actual user ID at runtime since we cannot checkin a real password into CVS / git.
     

    So did our original build automate the process of patching a user id, password and address?  Was there a particular machine used for the target address?  Is the current build still trying to do this? 


      Second, when RSEFileStoreTest.testModifyNonExisting() is exercised, the following check is made to determine why the input stream can't be opened:

      int code = ce.getStatus().getCode();
      assertTrue("1.6.1", code == EFS.ERROR_NOT_EXISTS || code == EFS.ERROR_READ);

      Right now we don't get EFS.ERROR_NOT_EXISTS nor EFS.ERROR_READ as the code but we do get
      EFS.ERROR_NO_LOCATION.  Should the assertTrue instead be as follows?
      assertTrue("1.6.1", code == EFS.ERROR_NOT_EXISTS || code == EFS.ERROR_READ ||
       code == EFS.ERROR_NO_LOCATION);

    The original idea of those tests was that when EFS is backed by the RSE file system, the same behavior should be shown as when EFS is backed by the original local file system provider from Platform.
     

    If I remember right, the RSEFileStoreTest can run against different EFS providers, and when the connectionType is set to null on top of the file it will run against the local file system provider such that you can see how it behaves. 

    I see that the RSEFileStoreTest.suite() currently has the following code:
    //// Add a test suite for each connection type
    //String[] connTypes = { null, "local", "
    ssh", "ftp", "linux", "windows" };
    String[] connTypes = {
    null, "local" };
    //String[] connTypes = { "
    ssh" };
    This means that by default, we're only testing this with local.  Did our original build only do this with local or was the code changed to do ssh or the combination of systems?
     

       

      Finally, the other two failing cases involve SimpleCommandOperation with a null ShellSubsystem.

      java.lang.NullPointerException
      at org.eclipse.rse.subsystems.shells.core.model.SimpleCommandOperation.runCommand(SimpleCommandOperation.java:92)
      at org.eclipse.rse.tests.subsystems.files.RSEFileStoreTest.testDeleteSpecialCases(RSEFileStoreTest.java:368)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

      The thing is when I try to run the testcases from my dev environment, I never get to the SimpleCommandOperation stuff.  In my case, it doesn't get there because
      fHomeDirectory isn't set during the setup() calls.  I'm running this on Windows - not sure if that would make the difference.


    Sounds like either setup() should set the fHomeDirectory, or the actual code should deduce the home directory but doesn’t do so.
     

    The setting of fHomeDirectory changes depending on what connTypes was set to in the RSEFileStoreTest.suite().  For example, when I changed it to use "ssh", the tests did get to the SimpleCommandOperation.runCommand() calls. 

    Thanks, 

    Martin_______________________________________________
    tm-dev mailing list

    tm-dev@xxxxxxxxxxx
    https://dev.eclipse.org/mailman/listinfo/tm-dev_______________________________________________
    tm-dev mailing list
    tm-dev@xxxxxxxxxxx
    https://dev.eclipse.org/mailman/listinfo/tm-dev

GIF image

GIF image


Back to the top