Running a test

Running a test brings together an Environment and a Test.

The Environment defines the services around the system under test. The Test defines the request to execute, the expected response, and any expected service interactions.

During execution, E2Engine creates a runtime environment, executes the test request, observes interactions with modeled services, evaluates the expectations, and records the result as a TestExecution.

Execution flow

At a high level, a test runs through the following stages:

Environment + Test
        │
        ▼
Create TestExecution
     scheduled
        │
        ▼
Acquire runtime environment
        │
        ▼
Mount services and routing
        │
        ▼
TestExecution
      running
        │
        ▼
Execute test request
        │
        ├── evaluate response
        └── observe service calls
        │
        ▼
Evaluate expected calls
        │
        ▼
Record result
 passed / failed / error
        │
        ▼
Release runtime environment

Resolving the test and environment

A test run starts with references to an Environment and a Test.

E2Engine resolves both resources before execution begins. It then creates a TestExecution in the scheduled state and schedules the test for execution.

The TestExecution receives its own execution ID, which identifies the run and its result.

Runtime environment

Before executing the request, E2Engine creates a runtime instance of the selected Environment.

For each service in the Environment, E2Engine creates the corresponding runtime implementation:

• real HTTP service
• mocked HTTP service
• real gRPC service
• mocked gRPC service

The environment router exposes the service addresses declared in the Environment and connects them to their runtime implementations.

Conceptually:

                    Runtime environment

System under test
       │
       ├──────────▶ service A ──────────▶ real service
       │                 │
       └──────────▶ service B ──────────▶ mocked service
                         │
                         ▼
                  observed calls

This routing layer allows E2Engine to observe interactions with modeled services while the test is running.

Once the runtime environment is ready, the TestExecution changes from scheduled to running.

Executing the request

E2Engine executes the request defined by the Test.

For example:

request:
  http:
    method: POST
    url: http://127.0.0.1:8080/payments

The request is executed using the protocol-specific executor. E2Engine currently supports HTTP and gRPC tests.

The resulting response is evaluated against the response expectation defined by the Test.

For example:

expect:
  http:
    status: 201

A difference between the expected and actual response is recorded as a deviation.

Observing service interactions

While the test is running, calls passing through the Environment’s service boundaries are observed and recorded.

For example:

Test request
     │
     ▼
System under test
     │
     ├──▶ Fraud Service
     ├──▶ Account Service
     └──▶ Notification Service
              │
              ▼
        observed calls

Recorded calls can then be compared with the call expectations in the Test:

expect:
  calls:
    - service_id: fraud
      count: 1
      http:
        method: POST
        path: /check

If count is specified, exactly that number of matching calls is required.

If count is omitted, at least one matching call is required.

For mocked services, a request that does not match any configured fixture is also recorded as a deviation.

Determining the result

After the response and service interactions have been evaluated, E2Engine determines the execution status.

Status	Meaning
passed	Execution completed and no deviations were found.
failed	Execution completed, but one or more expectations were not satisfied.
error	The test could not be executed or evaluated normally.

A failed execution can therefore contain deviations such as:

expected status: 201
actual status:   500

or:

expected fraud calls: 1
actual fraud calls:   0

An execution error instead indicates a problem executing the test itself, such as a transport, timeout, runtime, or evaluation error.

Recording the result

The completed TestExecution contains the structured result of the run, including:

• the executed request
• the received response
• the expectations
• observed service calls
• deviations
• execution errors, if any

The result is persisted and can be retrieved after the test completes.

Once execution is complete, E2Engine releases the runtime environment and its associated resources.

See Executions for the TestExecution model and its result structure.