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
____________________________________
"Oberhuber,
Martin" ---22/01/2013 02:41:16 AM---Hi all, Comments inline below:
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
