Hi Kendar, I need your help. I need you to see me now as a customer, not as a
technician. ;-)
Our RCP to test is based on Eclipse 3.2.2 plugins. SWTBot is 3.3.2.
I can automate the test with SWTBot, even though the versions are different.
How? By copying 3.2. and 3.3 plugins into the same Eclipse folder. Then the RCP
application runs, which we want to test, and SWTBot runs over it because it has
its plugins (both 3.2 and 3.3).
But this has a side effect. Our RCP plugins then used 3.3 plugins instead 3.2
plugins because they were both in the same directory. For example
org.eclipse.ui_3.2.1.M20061108.jar and org.eclipse.ui_3.3.1.M20071128-0800.jar
This can be prevented by not just setting the dependency to a plugin but also
to set minimum and maximum version for that plugin dependency. But then I
looked into the transitive dependencies of "org.eclipse.ui". It depends on some
other Eclipse plugins and states a minimum version of 3.2 and an maximum
version of 4.0. So I guess that for the transitive 3rd party plugins a post 3.2
version could be used automatically, without the possibility to prevent it.
Of course that is not good for testing, since our RCP is specified to be based
on Eclipse 3.2 and *not* newer. The testing environment must not mix things up
to a higher version. I think you will agree on this.
The easy way out for you would be to simply tell that everthing prior 3.3 is
not supported by SWTBot. But if you do this, you would have a narrow version
support for RCP/SWT. Compare that with for example the log4j libraries (and
many others) which one can use even with JDK 1.2. Compatibility (backward and
forward) is really helpful for the users.
This problem will be a problem of many people wanting to test RCP with SWTBot.
Compatibility is always an issue. So I hope you are interested in finding
solutions, or at least one.
One solution could be to run SWTBot "standalone" or isolated in its classpath
requirement, and the RCP or SWT application standalone and isolated too.
Two VMs would be involved: one for the JUnit tests with SWTBot and one for the
RCP or SWT application which needs to be tested. It then would be no PDE JUnit
test but a simple JUnit test by the way.
The RCP/SWT client could be started from the JUnit tests (Runtime.exec(...) or
whatever). Currently SWTBot would not find the display this way, since it only
searches in its own VM. If SWTBot can find the display in another VM, the
compatibility problem - which I mentioned above - could be solved I think. And
it would be easier to automate running RCP tests from Ant or Maven since it
would be a simple JUnit test (and no PDE Plugin JUnit test).
Thats the idea. How to solve it? I asked how to get the threads from another VM
in the Sun forum. They provided some solutions, which I need to verify:
http://forum.java.sun.com/thread.jspa?threadID=5313584
I think SWTBot could benefit by solving this compatibility issue. I would be
very intrested what you think about this idea and about increasing
compatibility.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
SWTBot-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/swtbot-users
http://swtbot.org/ - a functional testing tool for SWT/Eclipse
