Skip to content
Marriska Docs

Group tests to run together with test sets

A test set is a named group of tests you run together — your smoke suite, your checkout flow, your nightly regression. One run, one report, one schedule. Test sets live inside a project, and a test can belong to as many sets as you like.

This page covers the general mechanics. For the deeper dive on independent mode (setup/teardown hooks and retries), see isolating tests with precondition and recovery hooks.

Create a set and add tests

Section titled “Create a set and add tests”

  1. Click “New” (or “New Set”) in the test-set picker on the Runner page and give it a name.

  2. Add tests by checking them in the set’s tree. Checking a test adds it; unchecking removes it. Tests are added to the end, in the order you check them.

You can also clone a set (it copies the members into a Copy of … set), rename it, or delete it from the set’s … menu.

Does order matter?

Section titled “Does order matter?”

Each test in a set runs in its own fresh browser — Marriska doesn’t carry cookies or local storage from one test to the next (that’s true in both modes; see below). So a later test can’t inherit a browser session from an earlier one.

Order still matters when tests share your app’s backend state — a test that creates a record, followed by a test that opens it. Put those in the right order. For unrelated tests, order only sets the sequence you see results in.

Sequential vs. independent mode

Section titled “Sequential vs. independent mode”

Set the mode in the set’s Settings… dialog. Default is sequential.

SequentialIndependent
Run orderIn order, one after anotherIn order, one after another
Browser per testFreshFresh
Setup / teardown hooks—Precondition + recovery test per test
Retries on failure—Up to 5

Since neither mode shares browser state, the real reason to pick independent is the extras: a precondition test that runs before each test (a Login, say, so every test starts logged in), a recovery test that runs after each (a cleanup that always runs, even on failure), and retries. Reach for independent mode when each test needs the same known starting state, or you want automatic retries. Otherwise sequential is simpler.

The full how-to for those hooks and retries lives in the independent-mode guide.

What happens when a test fails mid-set

Section titled “What happens when a test fails mid-set”

The run keeps going. A failed test is recorded and the set moves on to the next one — there’s no “stop the whole set on first failure” switch. The only thing that halts a set early is you hitting Stop (see Running tests).

Run a set

Section titled “Run a set”

Click the ▶ Run button on the set’s header. The run-config popover lets you pick browsers and, if a local agent is connected, Cloud or Local — then Run now. The set runs as a batch: one run with a row per test.

Parameterized tests expand inside the run — a test with five data rows shows up as five items. The batch report rolls up passed / failed / skipped across everything; you can drill into any single test’s report from there. See Reading a run report.

Schedule a set

Section titled “Schedule a set”

Schedules target test sets, not individual tests — so to run something automatically, put it in a set first. Then follow How to schedule tests.

Limits

Section titled “Limits”

Test sets are unlimited per project on every plan, and there’s no cap on how many tests a set can hold.

Section titled “Related”