Marathon always supported modules (called capture scripts in earliest versions) that allowed us to create methods that can be inserted while recording test scripts. Version 3.0 brings a lot of enhancements to modules and MarathonITE goes one better by providing a ‘Extract to Module’ refactoring.

Advantages of using Modules

• Repeating the obvious, a major advantage of using modules is to structure the test scripts and reduce the repetition. This is why we split our code into methods – so that pieces of it can be reused and we can localize the changes.

Module methods allows providing default values for parameters. While inserting a method, we need to change only few values.

• Marathon modules allows parameterization. So when we are inserting a script, we provide the parameter values. By using default values in the parameter lists, we can insert a script by changing only a couple of parameters and having a long parameter list to a module method is not an impediment.
  In one of our earlier automation projects, we have a module method that accepted 16 parameters. But when we are recording a test script, in most cases we want to change only a couple of values (though different ones). Marathon modules is a good fit for this case.
• New in Marathon 3.0, we can filter modules that are valid for the current window.
• New again in Marathon 3.0, if a default value for a parameter is a list – that is considered as a list of valid values and insert script dialog displays a drop-down list from which we can select a value.

A Sample Module

Let us look at a sample module. This module has a method enter_widgets that enters values into the SampleApp ‘Simple Widgets’ window. For the sake of syntax coloring – posting an image. Click on image to see full image.

We can see that the income, gender, country default values are given as a list and for the languages the default values are boolean (true/false). Also observe that, the module method also includes the with_window() call.

Inserting the Script

While recording, we can insert this script into the test. We can insert the script either from the ‘Insert Script’ command on the control center window or from the context menu that we can open for inserting assertions. When we click on ‘Insert Script’ Marathon opens up the following dialog:

Most of the items are self explanatory. Observe that the ‘boolean’ parameters automatically got a combo box with true/false values. The check box at the bottom (which is selected by default) filters and shows only the methods that are available for this window. That is the need for the with_window() call in the module method.

MarathonIte does Refactoring

When we use MarathonIte we get a option to ‘extract a module method’ option in the menu. Select a piece of test script and invoke this option to pull out a module method.

Through this window, we can extract the used constatnts into parameters. The ‘Module Parameters’ section displays the list of values we extracted into parameters – the line numbers of the places where the extracted values exist are shown in the brackets. Clicking on any line in the ‘Script Selection’ section displays the existing values in the ‘Constants’ table. Click on the checkbox to extract a constant into a parameter and the parameter is added to the ‘Module Parameters’ list. We can ofcourse, reorder the parameters using the Up/Down buttons.

Once the interesting values are extracted, we click on ‘Extract to Module’ button. Clicking on ‘Extract’ button extracts the method and adds it into the test script itself.

‘Extract to Module’ displays a dialog (shown below) where we can enter the method name, description and a module file.

Selecting an existing module file appends the method definition to end of the module file. Finally, the script is modified to use the newly created module method.

Conclusion

One more addition to Marathon 3.0 is discussed here. In addition to this, ‘New Module Function’ option also has been updated to create a new module function and also append to an existing file. Marathon’s module functionality should make it easier for us to create reusable modules and to localize changes into fewer methods.

Though similar to a general ‘Extract Method’ refactoring (try it out with local variables – MarathonIte handles them properly) – MarathonIte’s ‘Extract to Module’ refactoring is specific to Marathon. The extracted module also includes the with_window() call if the selected code is within a with_window block.

If you have any suggestions or comments feel free to post them here or join marathon-testing google group for discussion.