Test Execution System
Overview
The Rhesis test execution system provides a flexible and extensible architecture for running tests against endpoints. It supports multiple test types and execution modes, enabling you to test everything from simple API responses to complex multi-turn conversations.
Architecture
The system uses the Strategy Pattern to route tests to appropriate executors based on their type:
Key Components
-
Test Execution Entry Point (
test_execution.py)- Main
execute_test()function - Routes to appropriate executor via factory pattern
- Maintains backward compatibility
- Main
-
Executors (
executors/)BaseTestExecutor- Abstract base classSingleTurnTestExecutor- Traditional request/response testsMultiTurnTestExecutor- Agentic multi-turn tests using Penelopefactory.py- Routing logic based on test type
-
Shared Utilities (
executors/shared.py)- Common helper functions
- Data retrieval and validation
- Result storage
Test Flow
Standard Execution Flow
Parallel vs Sequential
Test configurations can execute multiple tests in two modes:
- Parallel (default): Tests run simultaneously using Celery workers
- Sequential: Tests run one after another
See Execution Modes for details.
Executor Pattern
Creating an Executor
All executors must implement the BaseTestExecutor interface:
Return Format
All executors must return a dictionary with:
test_id(str): The test identifierexecution_time(float): Execution time in millisecondsmetrics(Dict[str, Any]): Metric evaluation results
Usage Examples
Running a Test
Using Executors Directly
Extending the System
Adding a New Test Type
- Create the Executor
- Update the Factory
- Add Test Type Enum
Design Principles
Modularity
Each executor is self-contained (~150-200 lines) and handles one test type.
Loose Coupling
- Executors don’t depend on each other
- Multi-turn executor preserves Penelope trace as-is
- No tight coupling to external frameworks
Backward Compatibility
- Public API (
execute_test()) unchanged - Helper functions re-exported for existing code
- All existing tests work without modifications
Extensibility (Open/Closed Principle)
- Add new test types without modifying existing code
- Factory pattern enables clean routing
- Easy to test executors independently
Performance Considerations
Execution Time Tracking
All executors track execution time in milliseconds for monitoring and optimization.
Caching
The system checks for existing results to avoid duplicate test execution.
Parallel Processing
Use parallel execution mode for independent tests to maximize throughput.
Module Location
The test execution code is located in the backend repository but is primarily executed by workers:
Related Documentation
- Test Types - Single-turn vs Multi-turn tests
- Execution Modes - Sequential vs Parallel
- Background Tasks - Celery task system
- Architecture - Worker system overview