Muse tests do not require Selenium/WebDriver at all. However, Muse was designed specifically for testing with Selenium and Selenium/WebDriver support is bundled into both the Muse Test Framework and MuseIDE.

Naturally, the first step is opening a browser.


The Open Browser step requires a browser parameter. This specifies what browser is to be opened and it closely mirrors the BrowserCapabilities object in the Selenium/WebDriver Java API. There is currently no GUI support for specifying browsers - the only supported method is by referencing a project resource in the parameter. That project reference is a JSON file that specifies the type of browser and the browser capabilities. See firefox.json in the muse-examples folder.

Browser Providers

In addition to the browser parameter, the Open Browser command requires a provider parameter. The provider specifies how and where the browser is to be opened. Browsers may be opened locally if the browser driver is available or they may be opened remotely - in your Selenium Grid or a commercial provider, for example. See local-provider.json and remote-provider.json in the muse-examples folder.

Because Firefox is so well supported by Selenium and the driver is built into the distribution, Firefox is the default used by all the examples.

In this example, the browser is opened using the browser and provider configurations (project resources) described earlier:


Element Locators

Selenium locators are used to locate elements of a page. In the example below, XPath and link text locators are used as the source in the click step as well as the parameter to the elementExists() method in the verify step:


Web Pages

Muse supports modeling the elements that you want to test on a specific page along with their element locators. In this example, the page github-homepage contains just one element we are interested in, the explore button:


Once the element is named on a page and provided with a locator, the element may then be referenced anywhere that you would specify an element locator, such as the click step in the test below. This reduces duplication of element locator configurations. When changes to the application demand an update to the locator, you must only change the locator for the element in the web page. All tests that reference the page element will then use the updated locator. Hurrah!