Re: [tm-dev] renabling JUnits?

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

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.

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.

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.

Thanks,

Martin