Where he blogs about his eclipse musings
Open Source
Announcing a new release of SWTBot
May 29th
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
Apr 10th
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!
Dec 3rd
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
Sep 6th
SWTBot 1.2.0 released
Aug 30th
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
Jul 9th
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
May 22nd
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
Mar 20th
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 at EclipseCon
Mar 19th
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
Mar 5th
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.