Open Source

Announcing a new release of SWTBot

You can download the latest and greatest from the SWTBot download page.

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.

Run JRuby From Within A Jar And Package Your Own Gems Along

Jruby-in a jar already bundles rspec and rake, so the goal was to find out where it gets packaged.

Download the jruby source zip, extract it and open the build.xml file, search for “rspec” (there’s two occurences) and you’ll find that it’s passed in as an argument to the gem installer, add in another line with “cucumber”:

<target name="install-gems">
  <property name="jruby.home" value="${basedir}"/>
  <java classname="org.jruby.Main" fork="true" maxmemory="${jruby.launch.memory}" failonerror="true">
    <classpath refid="build.classpath"/>
    <classpath path="${jruby.classes.dir}"/>
    <sysproperty key="jruby.home" value="${jruby.home}"/>
    <arg value="--command"/>
    <arg value="maybe_install_gems"/>
    <arg value="rspec"/>
    <arg value="rake"/>
    <arg value="cucumber"/> <!-- add cucumber -->
    <arg value="--env-shebang"/>
  </java>
</target>

Then run ant:

$ ant jar-complete

To verify that everything is fine:

$ java -jar lib/jruby-complete.jar -S gem list

*** LOCAL GEMS ***

builder (2.1.2)
cucumber (0.2.3)
diff-lcs (1.1.2)
polyglot (0.2.5)
rake (0.8.4)
rspec (1.2.2)
sources (0.0.1)
term-ansicolor (1.0.3)
treetop (1.2.5)

Great we’ve now managed to package jruby-in-a-jar with some additional gems. Now to run cucumber on jruby in eclipse.

SWTBot has moved to eclipse.org!

SWTBot has finally moved to eclipse.org.

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!

SWTBot Proposal at Eclipse.org

SWTBot has been proposed as an eclipse project.

Everyone is invited to comment on and/or join the project. Please send all feedback to the SWTBot newsgroup (web link).

See you all there.

SWTBot 1.2.0 released

For the impatient:
Direct download link: https://sourceforge.net/project/showfiles.php?group_id=188411&package_id=220519&release_id=622752

Update site: http://swtbot.sourceforge.net/latest/update-site/

SWTBot 1.2.0 is the 3rd of the 1.x releases of SWTBot was released last night, and there have already been about 200 downloads by the time of writing this blog post.

SWTBot has always believed in release early release often mantra, and pushes out nightly builds out of CruiseControl. From the download stats I’m looking at, there are more downloads of the nightly build than the ’stable’ available on the sourceforge mirrors.

The highlight of the release is support for view menus and view toolbar.

Thanks to the contributors and adoptors, for patches, criticism, and suggestions for improvement. The release has fixed about 42 issues.

Read more on the detailed release notes and the changelog.

Growl notifications from ant

If you use ant to run your builds, and would like to receive growl notifications about execution status, presenting Growl notifications for ant.

All you need to do is execute:

ant -listener com.google.code.ant.growlnotify.GrowlListener

And you’ll need is the growlnotify binary somewhere on your path, this is bundled with the Growl binary dmg.

Announcing SWTBot 1.0

I just made new release of SWTBot – 1.0

Direct download link: http://sourceforge.net/project/showfiles.php?group_id=188411&package_id=220519&release_id=601136

Update site: http://swtbot.sourceforge.net/latest/update-site/

Some features:

  • A recorder API — now you can record SWTBot scripts. Still in beta though.
  • Better SWTBot integration in eclipse — now you can run tests within eclipse.
  • More API — now you can use more SWT controls using an even richer API.
  • More stable than before.

For more details, you can read up on the release notes here.

SWTBot at EclipseCon

It is amazing how a talk at EclipseCon can get higher visibility to an otherwise unknown and unheard of project.

SWTBot.org was taking less than 10MB of web page views before, it now takes about 100MB, even before my talk is done with. I’ll let the graphs talk for themselves:

swtbot stats on sourceforge.net

SWTBot at EclipseCon

I’m sitting here at EclipseCon, and the coolest thing about this is getting to meet a lot of interesting people around.

A few folks spoke to me about SWTBot, and asked for a few feature requests. I promptly added those, and checked them into SVN, and my CruiseControl instance at ThoughtWorks says green. Hurray yet another build that can be pushed into production.

Catch hold of me if you are interested in knowing more about SWTBot.

Mockito – one of the better mocks

Now that I’ve got your attention. Mockito is not just better than the other mock frameworks out there, it’s infact the best out there.

After reading a lot of noise from fellow ThoughtWorkers in the recent past about Mockito. I decided to give a yet another mock framework a try.

Here’s what I ended up writing:

public class RecorderLauncherTest extends TestCase {

	private RecorderListener listener;
	private RecorderLauncher launcher;
	private TestRunner runner;

	protected void setUp() throws Exception {
		super.setUp();
		listener = mock(RecorderListener.class);
		runner = mock(TestRunner.class);
		launcher = new RecorderLauncher(runner, listener);
	}

	public void testNotifiesListenerWhenLauncherStarts() throws Exception {
		launcher.launch();
		verify(listener).start();
	}

	public void testNotifiesListenerWhenExecutionFails() throws Exception {
		stubVoid(runner).toThrow(new RuntimeException()).on().run();
		launcher.launch();
		verify(listener).start();
		verify(listener).error();
	}

	public void testNotifiesListenerWhenExecutionCompletes() throws Exception {
		launcher.launch();
		verify(listener).start();
		verify(listener).finish();
	}

}

What’s even nicer is that it’s actual code and not strings, and refactoring tests do not break my mocks.

Good bye expect-run-verify, hello run-verify.

This looks, and reads far better than the JMock syntax, and it was love at first sight; I’m test-infested now. If you have not tried mockito as yet, I’d recommend that you do. I’m sure you’ll love it too.