ChrisLMerrill edited this page Jul 15, 2016 · 51 revisions

Muse Test Framework

Muse executes a workflow assembled from individual steps, which are modeled in data rather than code. The primary use case is testing web applications by automating a browser with Selenium / WebDriver.

Muse was designed with these principles in mind:

  • tests should be developed primarily by testers
  • writing code to automate tests should an occasional solution to sticky problems, rather than a constant necessity
  • a testing tool should be easy to extend with custom capabilities
  • re-use of test logic and reducing replication of both data and code are critical to reducing the maintenance cost of automated test suites
  • test tools should integrate easily into agile development practices and CI build systems
  • open data formats increase value and reduce risk

Note: The Muse project is in the early stages...which means it is still in heavy development and has limited coverage of the WebDriver API. See the API Coverage map.

What do I get?

Downloading the distribution gives you the ability to:

  • integrate Muse tests into your build / CI server
  • convert SeleniumIDE tests into Muse tests
  • run Muse tests and test suites from a command-line interface

How do I get started?

Well, what you want to do?

I want to build tests

If you want to build and debug tests in a rich, visual IDE, you should install the (free) Muse IDE, which is built on this project. Take a look at the introduction, here. !!! LINK !!!

Also, see the Step Reference Guide and Value Source Reference Guide.

If you want to work on the command line and build tests by hand in a text editor:

  1. download and unzip this distribution
  2. from a command-line, cd to the /examples folder and run muse like this:

../bin/muse run testsuite

I want to develop custom steps or value sources

Download either this distribution or the Muse IDE and then read the Extending Muse guide.

I want to run my tests in our build system, test harness or CI server.

Download this distribution and read the Deploying Muse Tests guide.

How does Muse work?

Project Goals

To better understand what follows, it is worth taking a moment to explain the goals of the project:

  • Support higher-level tooling designed to reduce the difficulty of test construction
  • Encourage re-use within test assets
  • Decreasing long-term maintenance cost compared to similar tools (e.g. SeleniumIDE and Selenium Builder)
  • Easily extended via Java (and eventually Javascript)
  • Open text formats and file layouts friendly to version control systems
  • Command-line interfaces for convenient integration with agile processes and continuous-integration build systems
  • Free and open with business-friendly Apache2 license


Tests are modeled as a series of steps. A step may perform a trivially simple operation, such as incrementing a variable or writing a message to a log. Or it may wrap a lot of functionality, such as starting up an instance of a browser and connecting to it via WebDriver.

Each test executes a single step, which will nearly always be a compound step. This one contains three sub-steps:

"type": "steppedtest",
"step": { "type": "compound",
  "children": [
    { step 1... },
    { step 2... },
    { step 3... }

Steps can be nested as deep as necessary to accomplish the test goals.

Note: while JSON is the default format, all parsing of project resources happens in a extensible factory layer. Support for other formats is expected - for example: CSV or ODS formats for providing test parameters in a row-and-column tabular format.


As indicated above, steps may contain other steps. This allows grouping steps for readability or to create reusable functions (complete with parameter passing and isolated variable scope). It also allows for conditionals and looping.

In addition, each step has a type (required) and optional named value sources (aka parameters), to configure the behavior of the step. This example contains a type (goto-url) and a single source (URL).

    { "type": "goto-url",
      "sources": {
        "URL": { "value": "", "type": "string" } 

Note: this format is designed to be flexible, easy to parse and easy to manipulate with other tools, such as automatic test generators or a visual IDE. Human readability was a minor concern.

Value Sources

Similar to steps, value sources may be very simple, such as a constant or state variable. Or they could invoke more complex logic, such as extracting the source of a web page from WebDriver. In this example, the source for the condition parameter of a while step is a less than condition source, which contains two sub-sources - the left and right operands to the comparison.

{ "step" : { "type": "while",
  "sources": {
    "condition" : { "type": "lessthan",
      "sourceMap": {
        "left":{"type": "variable", "source":{"value": "counter", "type": "string"}},
        "right":{"value": 3, "type": "integer"}

There are many other test assets modeled in Muse, such as macros, functions, pages, browser. Learn more about them on the More Test Assets page.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.