Executions

An Execution represents a particular run of a test or test suite against an environment.

E2Engine has two execution types:

• TestExecution — one test executed against one environment;
• TestSuiteExecution — a test suite executed against one environment.

Executions are persistent resources. They record what was run, its status, and the structured result of the execution.

The execution model

A test execution brings an environment and a test together:

Environment + Test
        │
        ▼
  TestExecution
        │
        ▼
      Result

A test suite execution does the same for a resolved set of tests:

Environment + TestSuite
        │
        ▼
 TestSuiteExecution
        │
        ├── TestExecution
        ├── TestExecution
        └── TestExecution

The environment defines the topology.

The test defines the behavior.

The test suite defines the selection.

The execution records what happened.

Execution status

Both test and test suite executions use the same status model:

Status	Description
scheduled	The execution has been created and scheduled for execution.
running	Execution is in progress.
passed	Execution completed and its expectations were satisfied.
failed	Execution completed, but one or more expectations were not satisfied.
error	Execution could not complete normally because of an execution or infrastructure error.

The distinction between failed and error is important.

failed
  └── the test ran, but observed behavior did not match expectations

error
  └── the execution itself encountered an error

Test executions

A TestExecution represents one run of one test against one environment.

It records:

• execution ID;
• start and finish time;
• execution status;
• environment ID and name;
• test ID and name;
• structured execution summary.

For example:

id: f5497dfbbf8392b4828f5323c07e4b5cc8026790caca7b3065350413bebbd4e3
started_at: 2026-08-19T15:16:47.974744Z
finished_at: 2026-08-19T15:16:47.993394Z
status: passed

environment_id: 7398ab887149ec5aa583c564a659a0b0a933ef27bacb675b081a2a752d8a3896
environment_name: direct-real-http

test_id: ae619f9418f89041a5f6e0e952eae9fb9495e2c271b66739ffd6fae46f9ff30a
test_name: direct-real-http

summary:
  # ...

TestExecution fields

Field	Type	Description
id	string	Unique execution ID.
started_at	timestamp	Time execution started.
finished_at	timestamp	Time execution finished.
status	string	Current or final execution status.
environment_id	string	ID of the environment used for the execution.
environment_name	string	Environment name.
test_id	string	ID of the executed test.
test_name	string	Test name.
summary	object	Structured execution result.

Test execution summary

The summary captures the important evidence produced by a test execution:

TestExecutionSummary
    │
    ├── Request
    ├── Response
    ├── Expectations
    ├── Observed calls
    ├── Deviations
    └── Error

Request and response

request records the resolved request that E2Engine executed.

response records the response that E2Engine observed.

For example:

request:
  http:
    method: GET
    url: http://127.0.0.1:8083/ok

response:
  http:
    status_code: 200

Both HTTP and gRPC executions are represented in structured form.

Expectations

expect records the assertions evaluated during the execution:

expect:
  http:
    status_code: 200

  calls:
    - service_id: direct-real-http
      http:
        method: GET
        path: /ok

This preserves the expectations alongside the observed result.

Observed calls

calls records service interactions observed by the environment:

calls:
  - service_id: direct-real-http
    http:
      request:
        method: GET
        path: /ok
      response:
        status_code: 200

These calls provide structured evidence of what happened at the service boundaries described by the environment.

Deviations

When observed behavior does not satisfy an expectation, the difference is recorded as a deviation.

A deviation can contain:

Field	Description
field	Field or behavior that differed.
expected	Expected value.
actual	Observed value.
message	Additional description of the mismatch.

For example:

deviations:
  - field: status_code
    expected: "200"
    actual: "500"
    message: unexpected HTTP status

Deviations explain why an otherwise completed execution has status failed.

Execution errors

If the execution itself cannot complete normally, the summary can contain an error:

status: error

summary:
  error: failed to schedule test execution

This distinguishes execution failures from assertion failures.

Test suite executions

A TestSuiteExecution represents one run of a test suite against one environment.

Before execution, the suite selectors are resolved into a concrete set of tests.

Each resolved test receives its own TestExecution:

TestSuiteExecution
        │
        ├── TestExecution A
        ├── TestExecution B
        └── TestExecution C

The suite execution records:

• execution ID;
• start and finish time;
• status;
• environment ID and name;
• test suite ID and name;
• number of resolved tests;
• individual test executions;
• aggregate summary.

TestSuiteExecution fields

Field	Type	Description
id	string	Unique suite execution ID.
started_at	timestamp	Time suite execution started.
finished_at	timestamp	Time suite execution finished.
status	string	Current or final execution status.
environment_id	string	ID of the environment used for execution.
environment_name	string	Environment name.
testsuite_id	string	ID of the executed test suite.
testsuite_name	string	Test suite name.
tests_count	integer	Number of tests in the execution.
tests	array	Individual test executions.
summary	object	Aggregate suite result.

Test suite summary

A completed suite provides an aggregate summary:

summary:
  total: 3
  passed: 3
  failed: 0
  errors: 0

The fields are:

Field	Description
total	Total number of test executions.
passed	Number that passed.
failed	Number that completed with failed expectations.
errors	Number that ended with execution errors.
error	Suite-level execution error, when present.

The individual TestExecution resources retain the detailed evidence for each test, while the suite summary provides the aggregate result.

Executions are structured results

Executions are not only pass/fail records.

A test execution can preserve:

what was requested
        │
        ▼
what was observed
        │
        ▼
what was expected
        │
        ▼
which service calls occurred
        │
        ▼
where behavior deviated

This structured representation makes execution results useful to both developers and automated tooling.

The same execution model can be presented through different interfaces without changing its meaning.

Putting the concepts together

The four core concepts form one model:

Environment
    │
    │ defines topology
    │
    ▼
Execution ◀──── Test
    │           │
    │           └── defines behavior
    │
    └──── TestSuite
            │
            └── defines test selection

Or, more simply:

Environment + Test
        │
        ▼
  TestExecution

Environment + TestSuite
        │
        ▼
 TestSuiteExecution
        │
        ▼
  TestExecutions

The Environment defines the topology.

The Test defines the behavior.

The TestSuite defines the selection.

The Execution records the observed result.