I am writing this post so that it can be a reminder to myself as well as giving information to all of you waiting for a new release of Marathon. Since beginning of August I am full time working for my own company, so I am able to put in lot more effort in the development of Marathon. So what is going to be the release plan? The following are the tentative release dates for new versions of Marathon:

1. Version 0.91 – August 15th
2. Version 0.92 – August 28th
3. Version 0.93 – September 4th
4. Version 1.0beta – September 11th
5. Version 1.0 – September 18th

Version 0.91

The following features are added to Version 0.91:

1. Tabbed editor

   Now you can open multple testscripts/capturescripts and fixtures in the editor multiple tabs. Consider the current functionality as rudimentary. Some more enhancements are planned for 0.92. I faced a funny problem while developing this bit. Somehow, when we put up JEditTextArea components into a tabbed pane, the content of all the tabbed panes with JEditTextArea becomes the same. It turns out that JEditTextArea’s (from jedit-syntax package) uses a static TextAreaDefault object if default constructor is used. And the TextAreaDefaults has a document also!!

2. Docking

   The result window and console are docked to the bottom pane. You can switch between the two. The JUnit panel is docked to the Navigator window. You can open it by clicking on the JUnit button.

3. Capturing output from the Application under test

   The output (stderr/stdout) from the application as well as the test scripts is captured and displayed in the console window. The output from script (using system.err or system.out) is italicised. The stderr output is in red color and stdout is in blue color.

4. Runtime port

   Marathon uses RMI to communicate with the AUT. Setting up of this port was a major headache in the earlier versions. Now this port is dynamically allocated by Marathon, so you do not need to set marathon.runtime.port property.

5. Playing scripts with a delay

   Now you can execute the script with a delay from the toolbar using Slow Play command. The delay can be changed by setting marathon.runtime.default.delay to a different value (default: 1000 – i.e 1second).

6. Edit menu

   Undo/Redo/Cut/Copy/Paste are added to the Edit menu item.

Version 0.92

The concentration for 0.92 is on hardening of Marathon and providing support for Java 5.

1. Run unit tests in a loop.

   I added a junitrunner script and facility so that we can execute the UTs in a loop. Found multiple failures when the UTs are run like this and fixed all of them. At this time all UTs are passing.

2. Support for Java 5

   All the UTs should pass under Java 5. Should be able to run all of them in a loop. Found a problem with Java 5. See Window.dispose() can be a recursive call.

3. ComponentResolver and DefaultNamingConvention need to be updated

   I am planning for simplifying the naming conventions used. If we take into consideration that only components on the toplevel, focused window need to be named at any time – we may not need to consider the container objects within the window. Need to check this out. This will also solve the problem where-in different names are being generated for components in Java 2 and Java 5.

4. Fix some bugs

   Now when a play is stopped by the user by quitting the application, the display window can be restored to normal state by clicking on the ‘stop’ button. Similarly, while recording if the application is exited, the display window comes back to the normal state. (However, the last few clicks might not be recorded).

Version 0.93

1. Floating toolbar and hiding Marathon main window while recording

   I am excited with this feature. I do not know about others, but I am always irritated that the screen real estate is occupied by the Marathon main window while recording test cases. I am planning to hide the main window if you press the record button. A floating (always on top) tool bar will be displayed with stop/insertscript/pause etc. relevant buttons.

   It will also be nice to have a small text area in the toolbar where the current component name hovered on is displayed.

2. Assertions

   I might leave this for the next version (post 1.0), but I will mention the feature here. There are always requests for new assertions to be added to Marathon. If we can provide a mechanism by which the tester can define a new assertion while recording it might be of great value. While recording, we already know the current focused component. When the user opens the context menu, we can provide a option to record a new assertion. That can provide a list of all getters/is<XX> functions from which the user can select an option and can record a new assertion. Giving this a name make this assertion available when recording on similar components.

1.0 Versions

Mostly documentation and more documentation.

So what do you people think? If I missed out something that you feel should be there, please drop a mail to either the list or add a comment here.

Remember that Marathon can be improved only by feedback from its users.

This entry was posted on Tuesday, August 22nd, 2006 at 1:36 am and is filed under Marathon. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.