This purpose of this release is to work with the helios release and contains a few bug minor fixes.

A few other improvements were done to improve the code coverage for some plugins that were not tested too well.

Forthcoming releases will improve on the code coverage. Well, the irony.

An embedded console or an interpreter is a very powerful tool, it allows you to do some very interesting things with your software as it is running, play around with it, tweak it and anything else you can ever imagine. All of this without the edit-save-compile-relaunch cycle.

Lately I’ve been working on an embedded console for eclipse. The primary motivation was to try out scripting approaches for SWTBot. But I soon realized that I was using it for more than just scripting tests. I was using it to learn how eclipse works, try out different approaches to decide which one is best.

Some of the features include code completion, history lookup. This is possible using jruby’s objectspace and the readline support.

Here’s a small teaser video of what you can do with it an embedded jruby console for eclipse.

The update site url is here http://dl.swtbot.org/update-site

The example here uses SWTBot APIs. But there’s nothing stopping you from using anything else in any of your other plugins.

Ganymede is now almost 2 years old and the last bug fix release was in Feb 2009.

There has been a Galileo release of Eclipse in the Summer of 2009, and there is a new release Helios coming up the horizon.

Given this situation, it is very difficult to continue to provide a light weight testing tool that works across 3 different versions of eclipse on 4 different platforms linux, windows and macosx(carbon/cocoa) while backporting APIs that only work on newer eclipse versions.

In light of this, I’m considering dropping support for eclipse 3.4 for future releases. I’m happy to assist anyone wanting to contribute efforts towards maintaining a release of SWTBot for Ganymede.

The v2.0.0.568 of SWTBot made last night would be the last that supports Ganymede.

My mom would rather use a mac over a gentoo. A systems admin would rather use redhat over a mac on a production machine.

It is also important to say “NO” to people who are not your users. Almost all software at eclipse.org are frameworks, tools and app servers written primarily for developers.

The way software and API is designed for the developer is different from how it’s developed for the non-developer (most of the times). SWTBot was originally and still is primarily a test-automation tool for use by QAs to automate test cases. The APIs are designed to be extremely intuitive, simple and easy to extend by QAs by merely looking at examples and not having to read API documentation.

Some context is in order if you haven’t had the opportunity to work closely with QAs before. Most QAs I’ve met understand customer requirements, understand the software and what the customers want out of it. I like to treat them as end users of the buggy software I build. They may not understand SWT threading, the eclipse ui and platform, OSGi and how TCP packets travel across the corporate firewall over to a load distributor in front of a cloud hosted at a datacenter on the other side of the continent. Try explaining a “org.eclipse.swt.SWTException: Invalid thread access” to a QA and you’ll get interesting looks.

QAs are good at finding bugs in whatever software they are testing. Testing all of the software is time consuming, not to mention testing backward compatibility with older software. Nobody likes clicking around the same navigation path in the UI all the time.

QAs like exploring interesting ways to use the software and ensure that it works consistently as software evolves over time. The traditional favorites have been the ‘heavy weight’ automation tools like HP’s QTP, IBM’s Rational Robot, Borland’s SilkTest and the open source ‘light weight’ tools like selenium, sahi, and a lot others.

Each of these tools has its advantages and disadvantages. One of the most powerful features of each of these toolchains is the ability to author scripts in a dynamic language. The commercial vendors use vbscript or some other variant of the language, and provide some forms of integration with defect tracking tools. The open source tools are primarily light weight, use the languages like javascript, ruby, python and don’t integrate much with anything but your IDE and things like ant or rake.

The end goal is to make SWTBot an extremely good, open source, light weight tool for QAs to automate tests, and be just about useful for developers to write simple test cases with and not something in between that neither of them like.

As part of evolving SWTBot APIs we need to ensure that we stay true to our goal. This sometimes means saying NO to feature requests and even patches from developers if it hurts the non-developers.

I just realized that I had about 58 eclipse SDKs downloaded on my hard drive and 22 instances of different versions of eclipse. That was a whooping 9GB for the sdk downloads and 6.5GB for the extracted versions. Time to move to newer dope

Similar was the case on the cruise based build grid that tested SWTBot from all versions starting from eclipse 3.2 upwards to the latest RC build on all platforms — linux-gtk/linux-gtk-64/win32/macosx-carbon.

Eclipsetasy

A listing of some of the new features available:

Bug 263036 – SWTBot finally has an icon that was missing since two years!
Bug 269919 – Added support for toggle buttons
Bug 271246 – Better support for handling editors. This should serve as a good start towards providing support for multipage, forms based editors
Bug 271132 – Using Display#post() to support sending native click events instead of fake events. This is still work in progress and not all widgets support native events yet.
Bug 273624 – Use native keyboard events for typing. SWTBot currently defaults to using AWT robot. SWT’s Dispay#post() is available as well — it is however buggy across platforms and swt versions. Since SWTBot uses native keyboard events, it needs to understand various Keyboard Layouts.
Bug 267189 – Support capturing screenshots of widgets.
Bug 277093 – Support for Link widgets.

There are also a lot of minor bugs that were fixed in this release.

java.lang.AssertionError:
Expected: a string containing "... text=Ç..."
     got: "... text=Å..."

My immediate reaction was the encoding used by the JVM. Setting the “file.encoding” system property to UTF-8 did not help. Running the ant based tests in remote debugging mode also confirmed that the two strings were indeed different.

Since the tests used Cobertura for code coverage, the next step was to disable cobertura. Cobertura manipulates the generated byte code to add logging statements for code coverage. Still the same error.

The hidden gem seemed to be the -encoding java compiler flag. Setting it to UTF-8 fixed the problem.

So the next time you have something fail because of an encoding issue, it could just be the compiler encoding and not just the encoding used in the runtime!

My goal is to be able to write some user acceptance tests (using Cucumber) to be able to tests some of my Eclipse plug-ins.

Cucumber is a BDD framework written in (J)ruby. It executes plain text files as functional tests. As a first step, the goal was to be able to print a simple ‘hello world’:

This required being able to bundle jruby with the necessary gems, the jruby jar is already OSGi-fied, so creating a manifest was not required.

First drop in the jruby-complete.jar that we just created inside the target eclipse’s plugins directory.

Then create an eclipse application with the following in it:

public class CucumberRunner implements IApplication {

    public Object start(IApplicationContext context) throws Exception {
        Bundle bundle = Platform.getBundle("org.jruby.jruby");

        URL jrubyHome = FileLocator.toFileURL(bundle.getEntry("/META-INF/jruby.home"));

        RubyInstanceConfig config = new RubyInstanceConfig();
        config.setJRubyHome(jrubyHome.toString());
        Ruby runtime = JavaEmbedUtils.initialize(new ArrayList(), config);
        RubyRuntimeAdapter evaler = JavaEmbedUtils.newRuntimeAdapter();
        evaler.eval(runtime, "p 'Hello, Eclipse World'");
        JavaEmbedUtils.terminate(runtime);

        return EXIT_OK;
    }

    public void stop() {
        // do nothing
    }
}

Hello, Eclipse World

Now all we needed was to be able to execute the cucumber executable instead of printing hello world

Import the cucumber plugin with a sample calculator to execute it:

Cucumber Output

Hitler doing agile with very few unit tests + no nightly build = no safetynet.

Unfortunately this is quite representative of how a lot of eclipse projects work (ducks to take cover).

Are you builds running in the same way ? Do you write tests before you write code or test manually ? Do you run all the tests before you check in ? Do you have <a href="any CI server to run your builds on a variety of platforms that you support ? Do your unit tests have enough of code coverage to give you the confidence to refactor ? Is your build reproducible on any machine (in less than 5 manual steps) ?

If you’re answering no to any of the above, then this video is for you:

There is a bit of documentation sitting at the old home that needs to move to eclipse.org. I’m hoping to move this over in the next couple of days.

The sourcecode will also move during the course of the week. I’m busy renaming plugin IDs and packages to use the org.eclipse.swtbot namespace. Meanwhile you can participate on the newsgroups.

Cheers!