0

I would like to do functional test automation of a huge application consisting of more than 20 Eclipse RCP plugins. The most challenging part is almost all RCP plugins embed some legacy Swing components. Now I am almost certain that there is no open source test automation framework that supports testing SWT+Swing applications out of the box. There are frameworks that support testing pure SWT applications or pure Swing applications, but no framework supports testing an AUT that is a mix of SWT and Swing. I experimented something with a sample SWT+Swing application. This sample application is not an RCP plugin, but a stand alone SWT application with embedded Swing controls. I used two different libraries to test SWT and the Swing parts of the application.

For SWT, I used: https://github.com/mmarquee/ui-automation

For Swing, I used http://joel-costigliola.github.io/assertj/assertj-swing.html

It works just fine. I have a single Junit test that automates SWT as well as Swing components. So I am all excited to take this approach to test the RCP plugins.

So coming to my question: For the SWT part, I am fine, as the UI Automation binding works just fine with the SWT part of the RCP plugin. The problem is about using AssertJ Swing. AssertJ Swing uses a very different approach to attach to AUT. In fact it does not attach to a separate instance of AUT, but wraps the actual Swing components into something called as Fixtures. So the code that tests the Swing components using AssertJ Swing, must be running within the same JVM as the AUT. One idea is to implement a new RCP plugin and include the Swing tests within this RCP plugin. It may take some time for me to learn writing RCP applications. So I would like to ask if this solution has any potential problems. One problem that I already see is, will AssertJ Swing allow to find frames and dialogs without calling the ApplicationLauncher.application.start method?

Please note that, although this question sounds like it is about AssertJ Swing, and I am fine if I get answers and solutions around AssertJ Swing, I would like to hear about more ideas for solving the problem of testing multiple RCP plugins together which embed Swing components. I am open for a completely different approach, however I would like to stick to open source frameworks.

Heramb Deware
  • 21
  • 3

1 Answers1

0

You should create 3 testing projects:

1) An unbound project where you define your test-cases in general (think of it as a framework)

2) An RCP bound project, which imports the 1st

3) A Swing bound project which also imports the 1st

You define your test suites and AUTs in the latter two.

The tricky part is how you orchestrate the execution; you need to switch between AUTs when executing your job. It can be solved by writing a script program that calls the testexec binary of Jubula; selecting the appropriate project, test job, and AUT.

However it's not convenient. I believe it can be done from the user interface, without invoking the testexec. You need to create a fourth project which imports 2nd and 3rd and define your test jobs here. (the highest level of execution units) Only test jobs bind test suites to AUTs, so this could work out for you.

But I haven't tried if it's feasible. I'll edit my answer once I've found it out.

Adam Horvath
  • 1,249
  • 1
  • 10
  • 25
  • Thanks for the suggestion Adam. I will try to experiment this. However, if I understand it correctly, you are suggesting to use two different AUTs created from the same binary file. So in effect we would have two instance of the application to be tested. This is not feasible because there is too much switching back and forth between Swing and SWT dialogs and also the application is very huge, thus causing very high delay due to switching which will increase the test execution time. It is a nice suggestion though. I must try it with the sample application I have written. Thanks. – Heramb Deware Jul 14 '17 at 10:44
  • You are right; switching between projects can take several seconds when a project grows large in Jubula. Both at writing tests and when executing them. – Adam Horvath Jul 17 '17 at 08:33