---
title: All-in-One Execution Guide
slug: suite-documentation/all-in-one-execution-guide
docTags: 
createdAt: 2026-05-13T11:05:23.542Z
---

# Overview

All-in-One Execution runs scenarios in a defined order within a shared execution context.

To use All-in-One correctly, the test automation code must support two key rules:

1. **Execution order must be defined in the test code.**
   The scenario order is not configured from the UI. It is determined by the structure and order of the user’s test code, such as file, class, scenario, or method order.
2. **Driver lifecycle must be managed at suite level.**
   The driver should be created once at the beginning of the suite, reused across all scenarios, and terminated only after the suite is completed. Creating or quitting the driver per scenario may break the shared execution flow.

This guide explains how ordering works and how users should adjust their code for stable All-in-One execution.

:::hint{type="success"}
For Service/API tests, the second rule, suite-level driver lifecycle management, is not required.

This is because Service/API tests do not use a browser, mobile device, or driver-based execution environment that needs to be preserved across scenarios.
:::

# 1-Scenario Ordering

:::hint{type="info"}
Execution order cannot be managed from the UI. The order of the user’s test automation project code determines the execution flow.
:::

When **All-in-One** is selected, test scenarios run in a **deterministic, two-step order** that is fully defined by the test code.

1. **File or Class Order**
   - Test files or classes are executed **alphabetically by name**
   - Gauge uses `.spec` files
   - Karate uses `.feature` files
   - Java uses test classes
2. **Order Within Each File or Class**
   - After a file or class is selected, its scenarios or methods run **top-down**
   - The order of the user’s code determines the execution flow

## Example

Project files:

:::BlockQuote
01\_Login.spec
02\_Profile.spec
:::

Execution order:

1. `01_Login.spec` runs first because it comes earlier alphabetically
2. `02_Profile.spec` runs next

Inside `01_Login.spec`, scenarios run top-down:

:::BlockQuote
Scenario: Login
Scenario: Verify dashboard
:::

After all scenarios in `01_Login.spec` have finished, execution proceeds to `02_Profile.spec`.

## Ordering Notes

- Alphabetical file or class order is always evaluated before scenario order
- Renaming files or classes directly affects execution priority
- Sequential execution should be used only when scenarios depend on each other

# 2-Driver Lifecycle

All-in-One execution requires the test automation project to be designed for suite-level execution.

Since all scenarios run in a shared execution context, the driver lifecycle must also be managed at the suite level. If the driver is created and terminated for each scenario, the shared flow may be broken and the expected All-in-One behavior may not be achieved.

## General Driver Lifecycle Principles

For All-in-One executions:

- Driver **must not** be created per test or per scenario
- Driver **must** be created at suite level
- Driver **must** be reused throughout the execution
- Driver **must** be terminated only after the suite ends

## Framework-Specific Driver Lifecycle Standards

### Gauge (Java)

**Rules**

- Driver **must** be created using `@BeforeSuite`
- Driver **must** be terminated using `@AfterSuite`
- Scenario-level hooks such as `@BeforeScenario` should not be used for driver creation in All-in-One executions

Gauge treats a suite as a collection of specification files.

`@BeforeSuite` is executed once before the suite starts, making it the correct entry point for All-in-One executions.

**Recommended Implementation**

```java
@BeforeSuite
public void beforeSuite() {
    DriverManager.createDriver();
}

@AfterSuite
public void afterSuite() {
    DriverManager.quitDriver();
}
```

### Cucumber (Java – version 7.x.x)

**Rules**

- Driver **MUST** be created using @BeforeAll
- Scenario-level @Before hook **MUST NOT** be used
- @BeforeAll is available starting from **Cucumber 7.x**
- The method **must be static**

**Recommended Implementation**

```java
@BeforeAll
public static void beforeAll() {
    DriverManager.createDriver();
}

@AfterAll
public static void afterAll() {
    DriverManager.quitDriver();
}
```

### JUnit (Plain Java / Selenium / Appium)

**Rules**

- Driver **MUST** be created using @BeforeAll
- Driver lifecycle **must be suite-level**, not test-level
- @BeforeAll methods **must be static**
- Driver must be stored as a **static field**
- Scenario-level @Before hook **MUST NOT** be used

**Recommended Implementation**

```java
@BeforeAll
static void beforeAll() {
    DriverManager.createDriver();
}

@AfterAll
static void afterAll() {
    DriverManager.quitDriver();
}
```