Sessions

Everything the tutorial has built up in the controller so far is one session: the items loaded into the tree, the values planned for each test, the groups taken out of the plan, the endpoints picked, and the runs with their results. The session is the controller's workspace, and closing the window would lose it, so the controller saves it to a file and loads it back. A saved session is how a lab's setup outlives the evening it was made: the same tests, the same plans, the same machines, ready the next morning or on another controller.

A session file is a JSON file in the Sessions folder next to the controller's Logs. It records the loaded items by their paths, the plan and the draft edits of every test, which items are unplanned, the runs and their results, and the shape of the tree. It does not copy the suites: loading a session reads the tests again from their files, so a suite edited in the meantime comes back edited. An item whose file is gone by then is left out, and the controller says which, so the tree never loses an item in silence.

The unsaved session

The tree's top row names the session. A controller starts with New Session, and the star after the name says it holds changes that are not in any file. Load the tutorial suite, add the Structure and Lifecycle group and the Hello World test as items of their own, run the first two status tests and unplan the Advanced Configuration Parameters group, and the row reads:

The star appears on any change that a save would record: an item added or removed, a plan updated, a row planned or unplanned, a run started. It is the cue that closing the controller now would lose something.

Saving

Click Save in the Session action frame. A file dialog opens in the Sessions folder with the session's name proposed; give the file a name that says what the session is for, here statuses-lab. The controller confirms where it wrote:

The session row takes the file's name and loses its star:

From now on the name is the session's, and the star tracks changes against the file. Unplan one more group and it is back:

Save again to write the file over. A session that is running tests can be saved too: the file records the running tests as stopped and the queued ones as dequeued, since neither can be resumed from a file.

Starting over

New empties the tree. With unsaved changes on the row, the controller asks first, because the work would be lost:

Confirm, and the tree holds only the session row, back to New Session, and the Add Item placeholder:

Loading

Load opens the same file dialog on the Sessions folder. Pick statuses-lab.json. The controller reads every item from its files again, restores the plans, the unplanned rows and the runs, and the tree is as it was at the save:

The two runs are back with their statuses, times and logs, so the Details dialog and the log pane work on them as before. The Advanced Configuration Parameters group is still unplanned, and the plan count is the saved one. The Basic Configuration Parameters group is planned again, because it was unplanned after the save and that change was never written.

Loading into a session that has running tests stops them first, after a confirmation, since the tree is replaced whole. Loading never merges: to combine two sessions, load one and add the other's items with Add Item.

The session file is also what the controller keeps for itself between launches: closing the window and opening it again brings the last state back, named or not. Saving gives that state a name and a file that can be kept, copied to another controller, or loaded next to other sessions of the same lab.

The next page, Exporting Test Batch for CI, takes a composed session out of the controller altogether, into a form a pipeline runs.