About Me

My photo
I'm project manager of a software development team at www.researchspace.com. I've been developing bioinformatics software for the last 9 years or so, and I'm hoping to share some of the experience and knowledge I've gained with Eclipse RCP, Java web app development and software development in general on these blogs.

Friday, 7 August 2009

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 {






     // 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.



    } finally {

            // here we close our dialog



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.




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

Thanks for reading!