Context

Execution Context

Tasks operate within a MuseExecutionContext, which provide some services to the task. In fact, tasks typically execute within several MuseExecutionContexts of different types (they are hierarchical) and every context has a parent, except for the ProjectExecutionContext.

  1. Project context - everything runs in a project context
  2. Suite context - when running a suite of tasks
  3. Task context - when running a task
  4. Step context - for a step
  5. List Of Steps context - for a compound step

Services

Each context provides these services

  • Event logging
  • Variable storage and retrieval
  • Plug-in support

Events

When running a task, steps, value sources, plug-ins and other code can generate events. Each event has a type and can contain tags and attributes with additional data. Plugins can listen for events and take action. As an example, an Event Log Writer plugin can save the events to a file on disk.

When extending the framework with custom steps, the step may raise any of the event types already defined, but may also raise custom event types. For an example, see any of the events in the core.museautomation.builtins package - SetVariableEventType is a good example.

Variables & Scoping

Tasks can set and retrieve variables during execution using the Set Variable step and Variable value source.

Much like modern programming languages, the Muse Automation Framework supports variable scoping when executing a task. There are several built-in scopes and several that result from the design of the task. Scopes are hierarchical and all but the project scope exists within a parent scope.

  1. Project scope - everything runs in a project scope
  2. Suite scope - when running a test
  3. Task scope
  4. Step scope(s)
  5. Function scope

By default, variables created by the Set Variable step are stored in the Task scope (except for functions…see below). When retrieving a variable, using the Variable value source, every context will be searched starting with the local scope and working up the hierarchy until a value is found (except for functions, again).

Scoped group step

The Scoped Group step is a composite step that has it's own variable scope. By default, the root step in new tasks are Scoped Groups. While not required, this is a recommended design pattern that isolates variables initially set into the task scope and prevents them from being accidentally overwritten.

Function scope

Just like a modern programming language, when a task calls a function, the steps in the function execute in their own variable scope. Setting a variable in a function store the variable in the function scope. Retrieving a variable in the function will look in the function scope and then skip ancestor scopes until it reaches the Task scope, where it will resume the search.

This means that variables set in a task are not visible to the function and variables set in the function are not visible to the task. In place of this, functions can be passed parameters and can return values to the calling task.

Plug-in support

Plug-ins are initialized into an execution context before a task begins. This gives the plug-in access to task-scoped variables (and higher) and to events, via MuseEventListeners. Common uses for for these allow a plug-in to:

  • perform activities in response to task lifecycle events (start, end)
  • collect data from events
  • get/set variables