Sunday, May 23, 2010

Eclipse Plugins, Acceptance Testing, Jigloo

http://www.eclipse.org/articles/article.php?file=Article-Eclipse-and-Maven2/index.html

We have decided to not attempt to unit test SWT UI pieces - a decision, by the way, that is orthogonal to our choice of using Maven 2. Regardless of your build environment, Eclipse plugins are usually tested using JUnit and trying to automate SWT events etc. in that environment does not seem productive. By convention, we try to keep the UI layer as thin as humanly possible and keep all the business logic squirreled away in classes that don't interact directly with SWT and only sparsely so with JFace - making it much more natural to test with JUnit. Also, we tend to not directly unit test code that is generated (like EMF Ecore models or Hibernate POJOs) and since we use the very excellent Jigloo GUI builder from Cloudgarden to create all the Composites for our views, wizard pages etc. the amount of direct SWT code we write ourselves is fairly limited. Our company uses dedicated UI testing tools to do automated functional testing of the GUI.


We realized that the Eclipse plugins we write can be fundamentally put into two categories. We had Eclipse plugins that contained code in them, which we called Source Plugins and we had other Eclipse plugins whose sole purpose was to expose jars that other plugins depended on. We called these Binary Plugins. Just to be completely honest, we did have plugins that contained jars as well as code, but to keep things simple (as we like to do) we decided that it was easy enough to keep our Eclipse plugins purely source or binary.


Use Jigloo or Matisse?


Please don't use either! As with this answer, it's my strong opinion (after writing Swing GUIs for 10 years), that using GUI builders is, in all but the most edge-cases, a bad idea. HAND CODE YOUR GUI!
  • Whether you choose Matisse or Igloo, it is not a standard, will fall out of favour and a better tool will come along. At that point, you will have legacy code that is nigh on impossible to maintain. This has already happened severeal times in the history of Java GUI builders
  • You should avoid forcing your developers to use one IDE and it is a huge overhead to expect devs to switch to a particular IDE when looking at the GUI code. They'll be frustrated as they can't remember key bindings, project setup is out-of-date, they havbe the wrong version installed etc. People will make quick-fixes without the builder. At this point your code is unmaintainable in both your IDE of choice, and in the GUI builder istelf! The whole thing is a mess.
  • Designing a GUI is not, in my experience, a particularly onerous task and probably accounts for no more than 5-10% of the total development time of an application. Even if initially using Matisse or Igloo provides you with a 50% time advantage over hand-coding the GUI, this is insignifcant in the grand scheme of things. It is certainly not worth the hidden costs and impending maintenance disasters that lie ahead
  • GridBagLayout is not hard. It just isn't! It's really simple, in fact. It will take you a few minutes to learn and after that you'll never look back. Your GUI's will look like how you want them to look and your code will be more maintainable as a result. Use GridbagLayout!
I have spent a good deal of time warning people about this before and been proven correct.