MuseIDE 0.24 release

Summary

New Features

  • First implementation of support for step breakpoints while running tasks in the IDE (see below)
  • Add Close Window step (closes a window using the window handle)
  • Add Window Handles value source (e.g. <windows>.”length” to count the number of browser windows)

Enhancements

  • Set the correct default value for the Close on Exit parameter of the Open Browser step.

Bug Fixes

  • Improve propagation of Stop button event down to the task execution thread

Breakpoints

Set a breakpoint on a step from the pop-up (context) menu for the step:

breakpoints1

After selecting the Break item from that menu for a step, the task execution will pause before executing the step. Use Play or Step buttons to resume execution.

At this time, there is no indication in the step tree of which steps have a breakpoint set, but you can check a specific step to see if a breakpoint has been set  (note the check mark on the Break item):

breakpoints2

All breakpoints for the task are cleared when the task editor is closed.

Running Muse Tasks in Jenkins

A common use case for MuseIDE is building automated web tests, using Selenium. A common deployment environment for these tests is a CI/CD server, such as Jenkins. This post will show one way to accomplish this. Some of these techniques are applied in the muse-examples project.

Detect Environment

The first problem is: How can Muse detect the environment it is running in?

When Jenkins runs a job, it sets the JOB_NAME environment variable. Muse tasks and plug-ins can access environment variables via a System Value Source. This expression creates a value-source that evaluates to true when running in a Jenkins job:

not(($$"env"."vars"."JOB_NAME") == null)

The hostname can also serve as the decision point. It can also be accessed via the env system value source, such as this example that evaluates to true when running on the buildserver.

$$"env"."hostname" == 'buildserver'

Change Inputs and Outputs

The next problem, is how to change the behavior of the tasks. Two common needs, in handling differences between development and deployment environments, are:

  1. change the URL of the website accessed by a task
  2. change the location of the outputs of a task

Both of these can be solved by injecting values into a task with Variable List and a Variable List Initializer plug-in. There are several possible approaches – here I will describe the approach taken in the muse-examples project.

Step 1 – Create VariableList resources

First, I created 2 VariableList resources – one called project-vars and one called project-vars-local. The first contains general variables for the project and the CI/CD (Jenkins) environment. Note the URL.

varlist-default

The second contains only those that should be different when running locally (i.e. during development of the automation). Note the different URL.

varlist-local

Step 2 – Create Plug-ins

Next, I created two Variable List Initializer plug-ins in the project. The first injects variables from the project-vars list.

initializer-default

The magic happens in the second initializer plug-in. Note the Apply only if parameter. That condition will only run this plug-in if the JOB_NAME environment variable is null…which means when NOT running in Jenkins.

initializer-local

As a result, the URL from the first list will be overwritten from the URL in the second list and the second will be used in local development environment. The first URL will be used when running in Jenkins.

Step 3 – Order the Plug-ins

You may not have noticed that the Apply Automatically? parameter in both of the plug-ins is false, which means they will not be applied to tasks by default. Why? Because by default, there is no implied order that the plug-ins are applied. For many of the plug-ins, that is fine. But in this case, these two must run in the correct order, since the values from one must overwrite the other and not the reverse.

To ensure the order, the Apply Automatically? is turned off and these plug-ins are added to another plug-in, which IS applied automatically. This last plug-in is a List of Plugins, which simply contains a list of other plug-ins to apply. This allows the order of plug-in initialization to be controlled, ensuring that the general variables are applied first and the local variables overwrite them.

list-of-plugins

Note also that the Task Defaults Initializer plug-in runs after both of them. By default, this plug-in will not overwrite existing values, only injecting the defaults if none are present.

Alternate approach

Another approach would be to have only a single variable list initializer plugin that uses an environment variable to choose which list to apply (in the List id parameter). In this example, the list name comes from the INJECT_LIST environment variable.

var-list-env-alternative

This approach has two advantages – (1) using several different lists is easy and (2) plug-in order is irrelevant. The disadvantage is that all required variables need to be included in each list and values that are the same everywhere are duplicated.

 

Standard Output

Muse diagnostic log

By default, the Muse framework writes a diagnostic log to a local file when running a task or task suite.

$home/.muse/muse.log

In a CI/CD environment, this is not convenient. The management tools (Jenkins, etc) will capture the output written to the standard output stream (stdout) and make them conveniently available in the UI for diagnosing problems.

To better integrate into this environment, redirect the Muse diagnostic log to stdout. Two steps are required:

  • provide a logback configuration file that is configured for stdout logging
  • add a command-line option to use the stdout configuration file

These steps are described in the CI/CD Integration section of the user guide.

Muse event logs

Each task (or task suite) produces a separate event log. These can also be echoed to stdout, by configuring the Event Log Writer plugin. Set the //Log to stdout// parameter to true.

event-log-writer-config

Note that this is not a recommend practice for general use. It can be handy for diagnosing problems when you are initially setting up your execution environment, but should be reset to the default (false) when done, for these reasons:

  1. The Muse Automation Framework is designed to be capable of running tasks in parallel. The resulting output would be intermingled…and thus very, very difficult to comprehend.
  2. Failing tasks should be analyzed separately. Reporting plug-ins, such as the JUnit Report plug-in, can include the event log in the report output, making the relevant information conveniently available for each failure.

 

MuseIDE 0.23 release

This is a primarily a maintenance/bugfix release, with a handful of new features.

New Features

  • Selenium Switch To Window – a step for switching to a window by the handle
  • Selenium Switch To New Window – a step for opening a new window and switching to it (and optionally storing the window handle in a variable)
  • Selenium Capture New Window – a compound step for capturing the handle of a window created by a child step
  • Selenium Window handle source – a value source for returning the handle of the current window (e.g. “<window>”).

Maintenance and fixes

  • Re-organize some of the Selenium steps and value-sources in the menus
  • Fix bug in Move Mouse step
  • Expose configurable parameters in Event Logger plugin and add ability to log to stdout
  • Update to logback v1.2.3, which allows re-directing logging via the command-line

MuseIDE 0.22 release

This release brings a few new Selenium steps and a lot of maintenance under-the-covers.

I recently had a great opportunity to help a customer use MuseIDE to author tasks for general desktop automation. As a result, I have started efforts to widen the scope of MuseIDE to more general automation tasks – especially desktop automation and RPA (the framework was always designed to address automation beyond Selenium). As a result, much refactoring has happened under the covers, and this can be seen in the UI as tests are now referred to as tasks.

One side-effect of this change requires that users upgrade the PageObjects extension to 0.4 for compatibility with this release.

Selenium new features

  • Refresh step added
  • Set Browser Position step added
  • Browser Maximize step added
  • Browser Full-screen step added

Improvements

  • Selenium steps re-organized in the step-type menus

Bugs fixed

  • Fixed step-id bug that could cause confusion in the step tree, such as showing the state of the wrong step during debugging

Maintenance

  • Test resource type renamed Task (and TestSuite renamed TaskSuite)
  • internal refactoring (base package name changed from org.musetest to org.museautomation)
  • PageObjects extension upgrade will be required

MuseIDE 0.20 release

This holiday release contains some UI improvements, a few new steps and support for project subfolders. Also, the filename extension for Muse project resources is changing from .json to .muse (see below for more).

Additions and Improvements

UI improvements

  • Resources in the Project Navigator are sorted alphabetically
  • Step types and Value Source types are sorted alphabetically in the chooser drop-down selectors
  • In the Project Navigator, the project name is shown at the top, next to a new close button so you can close a project and open another without closing the IDE
  • Some internal/testing value sources that were visible in the type selectors have now been hidden (these were of no use and therefore confusing to users)
  • When creating a new project resource, the UI will indicate invalid resource names

Step types

  • Else step – for use after an If or Else If step
  • Else If step – for use after an If or Else If step
  • Download File step
  • Delete File step

Value Source types

  • “project-location” system variable added (technically not a value source, but it is accessible via a system variable value source (e.g. $$”project-location”)

Build environment

  • Most projects upgraded to Gradle 6.0
  • Compile target for most projects is Java 11, the latest LTS release (was previously Java 12, which may not fit well within many organizations)

Project Storage

  • The filename extension for project resources will be changing from .json to .muse (see below).
  • Project resources may now be stored in subfolders (see below).

Filename extension change

The filename extension for project resources will be changing from .json to .muse and this release is that start of that process. The reason for this change: I am planning future features that will allow JSON data from local files to be parsed and injected into Muse tasks (tests). Having two very different types of project data stored in files with the same filename extension would be confusing for users and perhaps error-prone for automatic recognition for by the IDE.

  • This release will recognize both extensions (.json and .muse).
  • New resources will be created with the .muse extension
  • Users will be notified of the change when opening projects with resources using the .json filename extension.
  • The notification includes a hint on how to mass-rename files from the command-line.
  • Support for project resources in .json files will be dropped in a future release.

Project sub-folders

Project resources may now be moved into sub-folders. This feature currently has no UI support, but you may make use of this feature by organizing the resources in the filesystem and declaring the relevant project folders for the IDE to scan in a configuration file. The config file, structure.json, should be placed in the .muse subfolder of the project

  1. Organize your files
  2. Create a .muse subfolder in your project folder (if it does not yet exist)
  3. Create a structure.json file in the .muse folder with the contents similar to the example below
  4. Add each folder to the subfolders array, separated by commas
{
"subfolders": ["login-tests","other_folder","etc"]
}

Additional notes:

  • folder structure is not reflected in the UI (yet)
  • resource IDs (i.e. filenames) must still be unique – the folder path is not part of the resource ID (this means you cannot have myresource.muse in multiple folders)
  • sub-folders and sub-sub-folders (etc) are supported, each needs to be listed separately in the config file, as shown below
{
"subfolders": ["folder1","folder1/subfolder1","folder1/subfolder2"]
}

Extension installer authoring

The support for automatic installation of project extensions now supports installation tasks authored within MuseIDE. The use of this feature is currently undocumented – for help with this feature, please contact me.