After reviewing several tools for writing UI tests for Eclipse based products, I finally settled down on SWTBot. Even after being a long time Eclipse plugin developer, I always found that I lacked a good tool for testing UI. I kept as much business logic code as possible away from UI code and wrote regular JUnit tests for that. But invariably, I ended up in situations where it made a lot of sense to write UI tests. What drove me towards SWTBot was the simplicity in writing tests, and also their ongoing effort in providing support for GEF (Graphical Editing Framework). Not to say that other tools do not provide nice features. I have heard that Window Tester from Instantiations is also good and provide good support. But SWTBot provided the quick start I needed to get some tests writting for the UI (ofcourse being an Eclipse project, and having an EPL license helps! ).

SWTBot is not part of the Galileo release train, but you can still use their plugins with Galileo (and that still qualifies my article for Eclipse Blogathon, I hope!). SWTBot is still an incubation project, and their support for GEF is currently hosted under Google Code. But even at this early stage, SWTBot is quite functional, and shows promise for becoming a robust test tool for Eclipse plugin and RCP developers.

SWTBot is launched similar to how a JUnit Plugin test is launched, except that an SWTBot launch runs in a non-UI thread. SWTBot also provides options to run in a headless mode, and an ant task to integrate for continuous testing. Writing test code with SWTBot is simple enough. The following code snippet opens the Import dialog to import projects into a workspace.

workbenchBot.menu(“File”).menu(“Import…”).click();

workbenchBot.tree().select(“General”).expandNode(“General”).select(“Existing Projects into Workspace”);

As you can see, the code is very readable and relatively easy to write. SWTBot lacks a Recorder (apparently there is one, but it is not actively maintained). In my opinion, a Recorder is useful only initially to get the hang of things, but once you start writing reusuable test modules, a Recorder loses much of its value. So I do not see it to be a big disadvantage, though having a recorder wouldn’t hurt.

If you are interested in trying out SWTBot, here are some resources to get you started:

SWTBot: http://www.eclipse.org/swtbot/

Eclipse UI Test Tools Comparison: http://wiki.eclipse.org/Automated_Testing#UI_tests

SWTBot for GEF: http://code.google.com/p/swtbot4gef/

KTable

The main advantage of KTable is that it is custom drawn. In some sense, this is a disadvantage too, since it does not use native SWT drawing techniques. But if you are looking for more control over the table’s functionality, then KTable might suit your needs. In my case, I needed control over the height of rows, more specifically, adjust the height of rows depending on its content. SWT Table had a Windows-specific issue that prevented individual rows from having different height. Also, once the height of a row is increased in an SWT Table, it can never be decreased. KTable helps overcome all these drawbacks. The latest version of KTable is 2.1.3 released in 2006, but it seems like bugs are still being fixed in CVS and the project is still active.

Eclipse Nebula CompositeTable

Nebula is a relatively new entry, but it is an Eclipse subproject, which gives it better visibility, and hopefully, stability. As of this writing, they are clearing out some legal issues; hence the binaries are not available for download, but you can still access the plugins and source code from CVS. Nebula’s CompositeTable is a custom SWT control which provides the flexibility to add any SWT control inside a cell. It also provides support for JFace Databinding to bind UI with model. The project is still in BETA. There is some discussion on absorbing this into mainstream SWT but it seems unlikely since Nebula does not follow the SWT principals of native drawing.

I have personally selected KTable for my requirements since it provides row resizing options that SWT Table or CompositeTable do not provide. But the jury is out there.

Being a regular user of Mantis, I have been acutely aware of the lack of an “industry practice” methodology in using the bug tracker. I have made an attempt to explain one such practice on the lifecycle of a bug. There are several other ways to use Mantis including more transition states, but what follows is what I have been using, effectively.

The state transition diagram is self-explanatory. There are four user roles – reporter, manager, developer, tester. Reporter reports an issue. Manager acknowledges the issue and assigns it to a developer, either as a single step, or in two steps. The bug can also be sent back to the reporter either by the manager or developer requesting for feedback. In such a case, the reporter adds the requested explanation. Once the developer resolves the bug (resolve can mean fixing it, marking it as not-fixable, marking it as not-reproducible or any other scenario). Finally, a tester closes the bug if it has indeed been resolved. If the tester finds the bug to be unresolved, it can be sent back to the developer. A bug can be re-opened after it is closed for several reasons such as, the bug being found to be unresolved after being closed, the bug having been closed as suspended (to be fixed later), etc.

There are several other ways to use bugtracker, by changing the state transitions, or by including new states (such as confirmed). They are useful in larger projects with more users involved.

Robocode Simulator

The impressive thing about Robocode is that we need not bother about the visual effects. How to draw the robot is not our concern. The Robocode simulator takes care of that. The battle is, I think, based on discrete event simulation.

Robot

Now coming to the interesting part. A robot is basically a tank with a body, a gun and a radar. Each component can move by itself, either independantly or relative to the component below (Radar is on top of the gun which is on top of the tank body). We need to define how the robot moves and how it handles different situations. What happens if the robot hits a wall (end of the battle ground)? What happens if the robot is hit by a bullet from another bot? The way each person handles these situations is what differentiates a simple robot from an exceptional one.
I am developing a bot myself (Mercury). It is ready for battle at the amateur level. It fights decently well with the sample bots but fails *miserably* against the pros . Please contact me if you want to discuss about the algorithm I have used or anything else regarding my bot.
I can rant on and on about what Robocode is all about. But I dont want to duplicate (or give false information!) about the details. I think the wise thing to do here is to give links to some good sites on Robocode. Which is what I have done below. Have Fun!!

Links

Robocode Site

Robocode Yahoo Group

Robocode Repository

Oracle – ADF Faces Core

Oracle – ADF Faces HTML