Execution Tab

Every page so far has worked inside the controller's Execution tab without describing it as a whole. This page does. The tab is the workspace of a session: the set of suites, groups, tests and batches loaded into the tree, the plan each of them carries, the endpoints they run on and the runs they have produced. Its parts are arranged around the tree:

the Session action frame on the left, whose buttons act on the whole session;
the Test Explorer in the middle, the execution tree with its filters above it and the action frame of the selected row beneath it;
the Endpoints panel below the tree, covered in Endpoints Management;
the right pane with Config & Status, the run panel and log of the selected row, and below it the Git Status and Execution Status frames.

The pages that follow go into the right pane frame by frame. This one stays with the left frame and the tree.

The Session action frame

A session is the unit the controller saves and loads. Its action frame gathers the operations that concern it as a whole, arranged in small groups from top to bottom:

New, Save and Load

These manage the session file. Save writes the loaded items with their plans and endpoint selections; Load brings such a file back, and New starts an empty tree. The session's name sits on the top row of the tree, with a star while it has unsaved changes.

Add Item

Add Item browses for a file to load: a batch, a suite, a group or a single test. Each becomes a top-level row, which is how the mixed session of Exporting Test Batch for CI was built.

Configure

Configure opens the run panel of the session row, the Multi-Test Selection layout with every planned test in its grid, from which the whole session is run or exported. Selecting the Session row in the tree opens the same panel, as selecting any row opens its own.

Dequeue and Stop

While tests are queued or running, Dequeue and Stop appear under Configure. Dequeue takes every queued test out of the queue and leaves the running ones to finish; Stop does the same and stops the running ones as well.

Unplan, Plan and Details

Unplan takes every planned item out of the plan, and turns into Plan when nothing is planned. Details opens the Details dialog at session level.

Clean Up and Clear

Both appear once runs exist and both keep the items. Clean Up removes the older runs of every test and keeps the latest one, running or finished, which tidies a tree after a day of reruns. Clear removes every run instance, finished or not, and leaves the items as if nothing had run.

Reload and Remove

Reload reads every suite and top-level group again from its files, which is what to click after a pull in the Git Status frame or an edit in the editor. Remove empties the tree: items and runs alike.

The frame shows only what applies to the session's state: the run and clean-up buttons are absent while the tree holds no runs, and appear as soon as one starts.

The collapsed frame

Click the arrow before the Session title and the frame folds into a strip of icons, leaving the room to the tree. Every button keeps working from the strip, with its name in the tooltip:

The action frame of the selected row

Below the tree sits a second action frame. It belongs to whatever row is selected and names it with its badge, so the buttons change with the kind of row. Selecting is itself an action: the configuration form of the selected row opens in the right pane at once, whether the row is the session, a suite, a group, a test, a test run or a set of rows picked with Ctrl. A single test gets its run panel; every other scope gets the Multi-Test Selection layout for the tests it covers. Configure in the frame brings that form back when another view has taken the pane.

A test row

For a test:

Configure opens the test's run panel in the right pane, which is also what a click on the row does. Unplan takes the test out of the plan, Details opens its Details dialog, which a double-click on any row opens as well, and Clear, present once the test has run, removes its run rows.

A run row

Select a run row instead, the italic Test Run line under the test, and the frame offers what a run supports:

A run cannot be unplanned, because it is not part of the plan; it is a record. Configure shows the configuration it ran with, whose buttons are Rerun and Reset To Run Settings rather than Run and Update Plan, as Editing run configuration showed. Details opens its results, and Remove deletes this one run.

Group and suite rows

A group's frame reads like a test's, acting on every test under it. A suite's frame adds the operations that make sense for a top-level item:

Label asks for a short text and shows it next to the suite's name in the tree, useful when the same suite is loaded twice from different checkouts:

Move Up and Move Down reorder the top-level rows, and with them the order in which the session is exported. Reload reads this one suite again from its files, and Remove takes it out of the tree.

A multi-selection

When several rows are selected with Ctrl and a click, the frame represents the selection as a whole:

Configure opens the Multi-Test Selection panel for the picked rows, and Unplan takes all of them out of the plan at once.

The Multi-Test Selection panel

Every scope wider than one test, a group, a suite, the session or a Ctrl+click set, is configured through the same panel, the one the CI page used to prepare its regression set:

Its upper part is a grid with one row per test in the scope, nested under their suites and groups, and one column per configuration field any of them declares; a test that lacks a field shows a dash there. A cell is edited in place, and a right-click on it offers Apply this value to all tests, which fills the column for every test that has the field, the way one Maze Executable Folder was set for a dozen tests at once. The lower part is the ordinary run panel of the test whose row is chosen in the grid, for the fields a grid cell cannot hold, such as case selection. The buttons act on the whole scope: Update Plan commits every edited cell, Reset To Defaults clears them, Run runs every planned test of the scope, and Export for CI writes the scope as a snapshot.

Every action of the frame is also in the row's context menu, so a right-click on a row does without the trip to the frame. The menu is built for the row under the pointer: a suite offers the full set, a run row only what a run supports:

A right-click on one row of a Ctrl+click selection opens the selection's menu instead, with the actions the Multi-Test Selection frame shows. Two shortcuts need no menu at all: a click selects the row and opens its form, and a double-click opens its Details dialog.

Plan and unplan

An item in the tree is either planned or not. Planned items are what the controller runs when the session is run and what an export writes; their cases are counted in the Plan column and roll up to the rows above. Unplanning is the way to keep an item loaded, with its configuration, while leaving it out of the next run: a group that is known to be broken, a slow test that is not wanted tonight, a suite kept in the session for reference.

Select the Basic Configuration Parameters group and click Unplan. The controller asks for confirmation, then greys the group and its tests, and their plan drops to zero. The suite's plan and the session's plan lose the same nine cases:

The group's action frame changes with its state. Unplan gives way to Plan, and Configure is gone, because there is nothing to configure for a run that will not happen:

Click Plan to bring the group back, with the configuration it had. The counts return to what they were. Unplanning applies at every level: a test, a group, a suite, a multi-selection, or the whole session from the left frame.

Filters above the tree

The row above the tree narrows what it shows without changing what is loaded. It holds status chips, the CI and H toggles and the level chips, followed by the collapse and expand buttons.

A status chip shows how many tests are in a state and hides the rest of the tree when clicked. There is one chip per state a test can be in, Running, Queued, Pass, Warn, Fail, Error, Dequeued, Stopped and Not Run, but a chip appears only while some test is in that state, so the row changes as runs start and finish. All counts every test and clears the filter. Click Fail and only the failing test remains, with its parents kept so it can be found:

A filter that runs out of tests, for example a Fail filter after the failing runs were cleared, drops by itself. The CI toggle, shown when the session holds tests configured for CI export, narrows the tree to those tests and combines with the status chips; the CI page shows it on a loaded batch. The H toggle beside it, shown when the session holds runs brought in from a run history file, narrows the tree to those runs; the Run History page shows it.

The round level chips collapse the tree to one level. G keeps the suites open and folds every group, which is the view used to pick groups for an export:

S folds the suites as well, leaving one row per top-level item:

T opens every container and folds the tests over their run rows, and a B chip appears when a batch is loaded. A chip is shown only when the tree has rows of its kind. The − and + buttons at the end collapse and expand everything.

Two views of the columns

The tree's columns fall into two sets. The Cases Summary set, Plan, Done, Pass, Fail, Progress % and Pass %, counts cases and is what the tutorial has read to check a run. The Status set, Endpoints, Status, Elapsed, Start Time and Finish Time, describes each run row: where it ran, how it ended and when. The two buttons after the Test Explorer title switch each set on and off, so the tree can show only the one that matters at the moment. With the Cases Summary hidden, the run rows get the room:

With the Status set hidden instead, the tree becomes a table of counts:

Both switches are a matter of display. The tree keeps counting and recording either way, and the Details dialog holds the full record of every run whatever the columns show.

The next page, Git Status Frame, moves to the right pane and the repositories the loaded items come from.