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.

MuseIDE 0.19 release

I’m please to announce we now have an installer/launcher for MacOS!  You can find it on the downloads page.

Additions and improvements

General features

  • Repeat Until and Repeat N Times steps provide additional looping options
  • Confirm before deleting project resources
  • Add MacOS installer
  • Remember divider position (between navigator and editor areas)

SeleniumIDE import

Support is added for importing the following commands when importing SeleniumIDE (.side) tests:

  • Select Frame N
  • Select Frame <id>
  • Select Parent Frame
  • Select Top Frame

Bug fixes

  • Fix the JUnit Report plugin
  • Fix editor button bug on first-opened editor
  • Fix selenium sub-group items in Add Steps list
  • Fix step-editor bug that sometimes edited the wrong step


  • Upgraded all projects to build with Gradle 5.6.2
  • Remove docking framework

MuseIDE 0.15 release

I’m excited to announce that MuseIDE is now open-source!  The underlying automation framework has always been open-source, but there are some parts of the UI that I cannot open-source as easily. It took a while to tease them out of the base IDE, but it is now done. You can find the IDE project on my GitHub – with Java 10 and a few Gradle commands, you can be running from source without too much effort. The binary distribution adds a few additional features (such as auto-updates and a UI for installing project extensions), but is otherwise just a more convenient way to install and run it. And, of course, you can dig into the source and contribute, too! I look forward to some pull requests 🙂

Additions and improvements

General features

  • Improve GreaterThanCondition and LessThanCondition sources to work with all native integer types. Previously, passing values from non-Muse sources might not have been compatible (e.g. in extensions, other libs, etc).
  • Set default value for the amount parameter in Increment step (to 1).
  • [n] notation can now be used to access items in lists in value source expressions (e.g. set $”item” to $”list”[n]).
  • New StringContains value source (with support for stringContains(string,target) expression)
  • New And and Or boolean value sources added (with expression support for || and && operators).
  • New StepWait plugin can add a delay after each step – to slow down the pace of the steps in a test.
  • New FindByRegex and FindNvpByRegex value sources can find single values or Name/Value pairs in a string using Regular Expressions. These are supported with the findByRegex(regex,string) and findNvpByRegex(regex, target, name_group, value_group) expressions

Selenium/WebDriver features

  • Run Javascript step now supports passing arguments to the script and returning a value to be stored as a local variable.
  • Element sources now have a find multiple parameter. When true, the source resolves to a list containing 0…N items. If none are found, the list is simply empty (not an error condition).
  • New value sources to retrieve the label of the item selected in a dropdown, the value of an element (e.g. an input field) and the editable state of an input. These are supported with the selectedLabel(), elementValue() and elementEditable() expressions.
  • New steps AcceptDialog, CancelDialog and SendKeysToDialog allow interacting with Javascript dialogs and alerts.
  • New steps for interacting with Select controls (drop-downs) include Select by Value, Deselect by Text, Deselect by Index and Deselect by Value.
  • New DialogText value source provides access to the text in a Javascript dialog (with support for the dialogText() expression).
  • The clear content parameter of the Send Keys step now defaults to true.
  • There is a new Keystrokes value source, which allows embedding special keys in strings for the Selenium Send Keys step. E.g. “{TAB}” or “{ESCAPE}”

SeleniumIDE import

Support is added for importing the following commands when importing SeleniumIDE (.side) tests:

  • check and uncheck
  • select, add selection and remove selection
  • assert title
  • echo
  • assert selected label and assert selected value
  • assert value
  • submit
  • set window size
  • assert element not present
  • assert alert, assert confirmation, assert prompt

Bug fixes

  • Fix cut/delete bug that caused test corruption when one of the selected steps is the child of another.
  • Fix to allow auto-expand and auto-collapse of steps (while stepping through a test) that are inside composite steps within a Function or Macro.


  • Upgraded all projects to build with Gradle 4.9

MuseIDE 0.14 release

The 0.14 release is primarily a maintenance and migration release. The app has been upgraded from running on the now-EOL Java 8 to Java 10. The transition was a big one – due to the modularization of the JRE in Java 9. The Muse framework uses Reflection extensively for dynamically loading new functionality in project extensions…and Reflection was greatly limited by the modularization changes. These same issues affected the launcher/updater – which needed to be migrated to a different project (to update4j from FxLauncher and javafx-gradle-plugin). Overall these changes are a good thing for Java and for this project, but it was a painful upgrade. The update to Java 11 looks to be relatively painless, with this behind me.

As a consequence of the above changes, the software will not automatically update to version 0.14. You must:

  1. un-install MuseIDE
  2. remove the app folder (C:\Users\<username\AppData\Local\MuseIDE)
  3. download and run the new installer

Thanks for your patience and support!

MuseIDE 0.13 release

In short:

Browsers can now be run in headless mode via the arguments in the browser provider configuration. Tests recorded or built with the new SeleniumIDE (3.x) can now be imported into MuseIDE from the .side file.

In detail:

Additions and improvements

  • Import new SeleniumIDE format files (.side)
  • BrowserProvider now has an arguments field that is passed to the browser startup command. E.g. “–headless”
  • ValueSourceDescriptors can now have a default value. This is useful, for example, on optional step parameters that should have a ‘true’ value when used.
  • All events are shown in the event log table, including those before the first step starts.
  • Updated to Selenium 3.11
  • Improve command-line output from tests
  • New WebdriverCapture plugin can collect screenshots, page content and log files for each step.
  • New EventLogWriter plugin writes events to disk as-they-are-received, instead of at the end of the test. Very useful when a browser hangs or test crashes due to unhandled errors.

Bug fixes

  • Fixed bug with copy and multiple-paste that caused step-ids to be duplicated, leading to UI corruption when stepping through a test.
  • Fix: Test Suite plugin failures do not show message to user (command-line or log file).

SeleniumIDE 3.x File Import (.side files)

The 0.13 release (coming soon) adds the ability to import tests in .side files – the format created by the newest SeleniumIDE (3.x). This is an enhancement to the existing import, which could import the previous SeleniumIDE format (.html).

To import SeleniumIDE tests into your project:

  1. Press the Import button in the project navigator
  2. Select the .side file
  3. Select the tests to import
  4. Press the Import N tests button

When selecting tests to import, the test name (assigned in SeleniumIDE) will be converted into a filename-friendly resource id. The new id is shown on the import screen and id conflicts will be indicated:


When selecting the tests to import, also you can see if tests have any unrecognized commands:


Tests with unsupported commands can still be imported – they will be noted in the step editor in MuseIDE along with their command names and parameters. You can then decide if these steps are necessary (SeleniumIDE records a lot of unnecessary steps). If you find there are critical commands that are unrecognized, please contact us. Frequently, these commands are easy to add and we can issue an update within a day or two.

The test editor indicates steps that use unrecognized commands with a red warning icon:


In this case, the mouse and scroll steps are unnecessary. Removing those steps results in a test that executes successfully. Your mileage may vary.

The ability to import .side files means you can record a workflow in SeleniumIDE and then quickly import into a MuseIDE test, rather than building the tests step-by-step. SeleniumIDE is available as an extension for Firefox and Chrome.


PageObjects extension for MuseIDE

One of my primary goals for the design of MuseIDE and the support for building Selenium-based tests is to lower the cost of building and maintaining tests built in a visual IDE.

There is a design pattern that test automation engineers use to reduce maintenance cost in coded tests: the Page Objects pattern. The purpose of the pattern is to separate the details of the page implementation (such as how to locate an element on a page) from the logic of the tests. In doing so, and by encapsulating the page implementation details into classes, duplication of those details is greatly reduced…or even eliminated entirely. In turn, this reduces maintenance cost because when those details change, they only need to be updated in one place. It can also reduce the cost of test development by building logic that can be re-used easily in future tests. Here is a more detailed code example of Page Objects in coded tests if you are curious to see what test code may look like.

When you look at the classes built for a Page Objects implementation, you are essentially seeing a model of the application – the pages and the elements, data sources and actions that are contained on each page. You may also notice that the things that are modeled (pages, elements, data sources, actions) will be very similar for each web application tested…even for applications that look very different on the surface. This implies an opportunity to build a general-purpose model and GUI that will serve for many or most applications.

Opportunities for re-use

Lets start by looking at the MuseIDE Selenium test shown below — it performs a few simple steps:

  1. Start at a URL
  2. Click a link to the login page
  3. Login (fill username & password, press login button)
  4. Verify the login succeeded
  5. If the logout button is present, press it, wait for completion and check for success
  6. Close the browser


The login process has been implemented as a reusable function, so that is good. But nearly every other step has details that are likely to be duplicated in other tests that deal with these pages. Some examples

  1. “Go to…” step has a hard-coded URL. Every test that starts on this page will have a copy…and they would all need to change if that URL changes.
  2. Each of the click steps contains an element locator, which may be duplicated in other tests.
  3. Each of the verify steps references a condition on the page, which is duplicated in the login function and may be duplicated in other tests as well.

Convert to use Page Objects

Here is the same test, converted to use the Page Objects extension. You will immediately notice two differences: (1) the test is much more expressive – anyone could read it and immediately understand what each step in test is doing – and (2) all of the nitty-gritty details of the implementation have vanished. You may also notice a 3rd difference – there is a little more hierarchy in the test. The steps are separated into those on the HomePage and those on the LoginPage.


So where did all the details go? They are moved into Web Pages defined in the project. The first, the HomePage, is very simple in this example, so lets look at it first.


The HomePage only has two components defined – the Page URL and one element – the LoginPageLink.


When the Start at Page step executes, it looks up the URL for the page and sends the URL to the browser. Each test that starts at the HomePage no longer duplicates the URL – it is defined in this one place.

One element has been defined on the page – the LoginPageLink. The element locator has been moved here and is referenced by name in the click step of the test.


The LoginPage has many more elements defined, as well an action and a few conditions.


The Perform Action step in the test references an Action on the page. The action simply references a function defined in the project.

The Verify and Wait steps in the test reference conditions on the page. Again, the details have been moved out of the test and into the page model.

Also notice that the conditions do not duplicate the locators for the elements they reference – they use a special notation to reference the element as defined on the page.

Login function

The login function was also converted to use Page Objects. Here is the initial version:


And here is the Page Objects version:


Converting the test to model the HomePage and LoginPage in this way has eliminated duplication of the element locators and conditions, as well as making the tests easier to read. When minor changes are made to the application that affect element locators, only the Page Objects will need updates. Each change will be made in just one place – reducing cycle time and lowering costs.

To get MuseIDE, download the installer.

To install the Page Objects extension into your project, press the Extensions… button in the project navigator, switch to the Available tab and press the + button next to the Page Objects extension.