Jemmy3, SWT and the Robot framework

[Ricardo de Matos]

Hello!

I'm included in a small team responsible for automate some test cases, through the robot framework, for an application developed in SWT.

To accomplish this we have considered the following options:

- use the eclipse library, which is a bridge for SWTBot (https://code.google.com/p/robotframework-eclipselibrary/);

- use Jemmy3 (https://jemmy.java.net/) as a driver to access the SWT components;

The eclipse library is no longer developed and it doesn't support testing graphs, which is one of the areas we want to automate.

Plus, it forces us to copy several files to the installation path to properly function.

I prefer the option of using Jemmy3 and follow a similar path as the SwingLibrary.

The problem here is that this SWTLibrary can not be implemented following the SwingLibrary as an example, because Jemmy3 is implement differently from Jemmy2, in which the SwingLibrary is constructed upon.

The documentation is also scarce for Jemmy, making it even harder to start building this new library.

Could some one provide some hints/support/help in developing this library ?

Thank you!

[Pekka Klärck]

2013/4/22 Ricardo de Matos <ricardo....@gmail.com>:

>
> I'm included in a small team responsible for automate some test cases,
> through the robot framework, for an application developed in SWT.
>
> To accomplish this we have considered the following options:
> - use the eclipse library, which is a bridge for SWTBot
> (https://code.google.com/p/robotframework-eclipselibrary/);
> - use Jemmy3 (https://jemmy.java.net/) as a driver to access the SWT
> components;
>
>
> The eclipse library is no longer developed and it doesn't support testing
> graphs, which is one of the areas we want to automate.
> Plus, it forces us to copy several files to the installation path to
> properly function.

Are you sure the EclipseLibrary isn't developed anymore? I know there
hasn't been releases recently, but that doesn't mean the project is
dead. Have you checked would it be possible to add graph testing
support to it and fix other problems you have encountered? Could be
less work than developing a totally new library.

I added Laurent Carbonnaux, the main developer behind EclipseLibrary
into Cc. Laurent, can you comment what is the status of the library?

> I prefer the option of using Jemmy3 and follow a similar path as the
> SwingLibrary.
>
> The problem here is that this SWTLibrary can not be implemented following
> the SwingLibrary as an example, because Jemmy3 is implement differently from
> Jemmy2, in which the SwingLibrary is constructed upon.

I've understood that Jemmy 3 is pretty much totally different than
Jemmy 2. They cannot apparently even be used for testing same UI
technologies. That's why SwingLibrary is not going to switch the Jemmy
3.

> The documentation is also scarce for Jemmy, making it even harder to start
> building this new library.

Yes, this is big problem with Jemmy, regardless the version.

Cheers,
.peke
--
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org

[Ricardo de Matos]

Hei Pekka, kiitos vastauksesta.

Bonjour Laurent, je vous remercie pour votre réponse.

As you mentioned, Pekka, the Jemmy documentation doesn't help us develop new libraries upon it and also there isn't the guarantee that it can test GEF components. So we decided to use the SWTBot and, as such, the EclipseLibrary.

We followed the tutorial available on https://code.google.com/p/robotframework-eclipselibrary/wiki/InstallationForEclipse and managed to make the test case work in our machines.

We succeeded in using the eclipsebot.bat and the swtbot.bat approach.

We also succeeded in using the eclipselibrary-x.x-with-dependencies-swt.jar and the standalone version.

What we did not succeeded was to run the test in a new Eclipse installation. 

In this case, the Start Eclipse keyword fails to start Eclipse.

After some banging on the wall, we discovered that we have to first open Eclipse through the eclipse.exe program (or through the command line java -jar eclipse/plugins/org.eclipse.equinox.launcher_1.0.0.v20070606.jar), because this allows the configuration directory (e.g. C:\Program Files\eclipse\Indigo\configuration) to be properly filled with the plugins data.

After this first start-up, the RF test succeeds.

Since the eclipse.exe is just a wrapper for the complete command line to start Eclipse, we tried to feed some of these command line options to the keyword Start Eclipse (e.g. -configuration file:/C:/Program Files/eclipse/Indigo/configuration), but with no luck.

We also tried using the keyword Start Application In Separate Thread and not only it has the same problem described for keyword Start Eclipse, but it also makes the remaining keywords of the test case to fail, because then the widgets can not be referenced.

Another test we made was to use the Start Application keyword.

In this case, Eclipse starts properly, even if it is the first time, but the widgets can not be referenced and so the test also fails.

We looked to the EclipseLibrary keywords source code, but it doesn't reveals a reason for this problems.

- Why starting an Eclipse instance in another thread requires it having the configuration directory filled?

- Why starting an Eclipse instance with the Start Application In Separate Thread keyword does not produces the same result as with keyword Start Eclipse ?

Laurent, can you please help us find the answers for these questions ?

Meanwhile we solved this problem by first starting Eclipse through the SWTBot command line and then we close it with a SWTBot test. 

After this we can use the EclipseLibrary to run our RF tests.

Not an elegant solution, in my opinion...

We are also planning on extending your library to support GEF, since SWTBot 2.1.0 has this functionality and we need it to achieve our goal.

Kiitos / Merci,

Ricardo de Matos
忘れていない

On Fri, May 3, 2013 at 6:37 PM, Laurent Carbonnaux <laurent.c...@gmail.com> wrote:

Hi All,

EclipseLibrary is still alive!

The fact it's seams not is that I didn't provide any new enhancement for a while, because I didn't need for my self use, and really no much time.

I at least give support to people who need help using it.

So if you want more, please ask for or help me develop it.

Regards,

Laurent.

2013/5/3 Pekka Klärck <pe...@iki.fi>