SWTBot tips

We are using SWTBot in our application to test an Eclipse RCP application.  In this blog I explain how it fits in with out system, together with some coding tips gleaned from experience.

Our RCP app is basically a rich  client for a scientific application - it has a complex UI with lots of forms, data validation, and visualization capabilities. It also launches long running calculations on a backend server, and interfaces with C libraries installed on the local machine. 

 We have 3 'layers' of testing:

• Regular JUnits
  
• SWTBot
  
• Manual system testing
  

SWTBot really slots in nicely here - our Junits cover numerical procedures, data validation etc , but do not cover the UI, as they are hard to write for code involving SWT widgets. 

SWTBot is great for fine-grained behaviour of wizards, dialogs etc. We still run these with 'dummy' server connections etc., so we can run them frequently. Our manual tests can now be restricted to 'sanity check' type tests before a release, i.e., testing configurations, checking that libraries are working outside the IDE, etc.,.

Here are some tips we've found useful in order to improve the reliability of the tests:

1. Always use a fresh, clean workspace for each test. We create a fresh project with the particular resources we need for a test, and delete it after each test in the teardown: 
2. It is REALLY IMPORTANT that each test tidies up after itself. It is all too easy for failing tests to leave the app with dialogs or error messages still showing.  We have found it useful to wrap test code in a try/finally block. The finally block closes any open dialogs before exiting the test. So, even if an assertion fails the app is left in a stable state for the next test. For example:

try {

bot.textWithLabel(OptimizationUserInfoPage.HOST_LABEL).setText(

SBSIPreferenceInitializer.DISP_SERVER_DEFAULT);

assertTrue(isNextEnabled());

bot.textWithLabel(OptimizationUserInfoPage.JOBNAME_LABEL).typeText(

"name2)");

     // if this assertion  were to be true, an exception would be thrown and without

     // a finally block the wizard would not be closed, screwing up the next tests.

assertFalse(isNextEnabled());

checkMultipleRapidKeypressesDoesNotCauseDisconnect();

    } finally {

            // here we close our dialog

bot.button("Cancel").click();

}

Why not just use the 'teardown' method? Well there may be different dialogs in the testcase that are being tested, so a single teardown method is not sufficient. 

3. Create a utility class that can do common tasks , for example testing wizard buttons:

   private boolean isNextEnabled(SWTBot bot) {

   // using a constant for the 'Next >' text prevents typo errors.

return bot.button(UI_STANDARD_NAMES.WIZARD_NEXT_BUTTON_NAME)

.isEnabled();

}

In future posts I hope to add to our SWTBot experiences.

Thanks for reading!