System-oriented
The environment is a first-class concept. Tests describe behavior inside an explicit topology of real and controlled services.
Why E2Engine?
The test system should bean explicit model.
Distributed-system tests often combine infrastructure provisioning, service mocks, requests, assertions, and custom orchestration. E2Engine brings those concerns together as a structured description of the system being tested.
The practical question
Why not just use the tools we already have?
You can. E2Engine is not intended to replace every integration-testing, mocking, or infrastructure tool. It addresses a different level of the problem: describing and executing a distributed-system test as one coherent model.
Typical composition
Test frameworkContainersHTTP / gRPC mocksFixturesSetup scriptsInteraction assertions
Powerful tools, composed and orchestrated by project-specific test code.
→
E2Engine
EnvironmentWhat participates
TestWhat should happen
ExecutionRun the system
ResultWhat actually happened
The test topology and behavior become explicit data rather than implicit orchestration.
The difference
A different testing abstraction.
Declarative
Test intent is represented as structured specifications instead of being embedded entirely in framework-specific orchestration code.
Interaction-aware
A test can verify not only its outward result, but also expected interactions across controlled service boundaries.
Machine-understandable
Environments, tests, executions, and results have explicit structure that can be consumed by developers, automation, and software agents.
Alternatives
Different tools solve different parts of the problem.
The useful comparison is not a checklist of features. It is deciding which abstraction best matches the test you need to build.
Real dependencies
Testcontainers
Testcontainers is a strong choice when tests should start and use real databases, brokers, servers, or other containerized dependencies directly from test code.
E2Engine addresses a different concern: modeling the distributed test environment and its expected behavior as a coherent executable specification.
Think: dependency infrastructure vs. distributed-test model.
Service virtualization
WireMock / MockServer
Dedicated mock servers provide sophisticated service virtualization, request matching, verification, proxying, fault simulation, and related capabilities.
E2Engine uses controlled dependencies as part of a larger test model that also describes the environment, executes the test, and records its result.
Think: specialized service virtualization vs. orchestrated system behavior.
API testing
API-oriented test tools
API testing tools are often the simplest choice when the main goal is to send requests to an API and assert its externally visible responses.
E2Engine becomes more relevant when the test also needs an explicit service environment and verification of behavior across service boundaries.
Think: test the API surface vs. test the distributed interaction.
Custom infrastructure
Test code + Docker Compose + mocks
Custom integration-test infrastructure gives a team maximum control and can be the right answer for highly specialized systems.
E2Engine is intended to reduce the amount of project-specific orchestration required when the same patterns — environments, mocks, execution, interaction verification, and results — recur across tests and projects.
Think: build the orchestration vs. describe the test system.
When to use E2Engine
Use it when the boundaries are part of the test.
E2Engine fits well when
- a service depends on multiple downstream services;
- some dependencies should be real and others controlled;
- HTTP or gRPC interactions are part of expected behavior;
- call parameters or call counts need verification;
- the same test model should work outside one test framework;
- structured execution results matter to automation or tooling.
Another tool may be simpler when
- you only need a standalone mock service;
- you only need a real database or broker for an integration test;
- you are testing a browser or user-interface workflow;
- simple request/response API assertions cover the requirement;
- your test requires highly specialized custom orchestration.
Designed for automation
The consumer of a test is no longer always a human.
Modern development workflows increasingly involve software agents alongside developers. A test model expressed through explicit structures is easier for both to create, inspect, execute, and reason about than behavior spread across scripts and framework-specific code.
This is an architectural property of E2Engine, not a separate AI testing mode.
HumanDeveloper
SoftwareAgent / Tool
↓
E2Engineone structured model
Get started