End-to-End & Fixtures
Relevant source files
The following files were used as context for generating this wiki page:
The End-to-End (E2E) & Fixtures system in FLEXT Observability provides a comprehensive framework for validating complete observability workflows, real-world usage scenarios, and cross-component integrations. This system ensures that the platform functions correctly from data creation to export, maintaining enterprise-grade quality through rigorous testing patterns and reusable test data structures.
Sources: tests/e2e/README.md:15-21, tests/README.md:21-25
End-to-End (E2E) Testing Architecture
E2E tests focus on the user journey and business outcome verification. Unlike unit tests that isolate components, E2E tests execute complete workflows using realistic data volumes and production-like configurations. These tests typically have a longer duration, often targeting execution times under 30 seconds per test.
Sources: tests/e2e/README.md:15-21
E2E Workflow Logic
The standard E2E workflow involves initializing the platform, generating diverse observability data (metrics, traces, and alerts), and verifying the end-to-end data flow into storage or external export systems.
This diagram illustrates the sequential stages of a complete observability workflow validation.
Sources: tests/e2e/README.md:41-60
Core E2E Test Scenarios
E2E testing is categorized into business-focused workflows and technical integration paths:
| Scenario Category | Description | Key Components Involved |
|---|---|---|
| API Monitoring | Request to Metric to Alert lifecycle | Platform, Metrics Service, Alerting |
| Error Tracking | Error to Alert to Trace workflow | Tracing, Logging, Alerting |
| Performance | Load testing with metrics analysis | Metrics Collection, Benchmarking |
| Health Checks | Status check to recovery workflow | Health Service, Alerting |
| Technical Integration | Factory-to-Service data processing | Master Factory, Metrics Service |
Sources: tests/e2e/README.md:104-118
Test Fixtures and Utilities
The fixtures system provides a centralized repository for reusable mock objects, consistent test data, and environment setups. This reduces duplication and ensures that unit, integration, and E2E tests operate on standardized data structures.
Sources: tests/fixtures/README.md:19-25
Fixture Categories
The system organizes fixtures into logical domains:
- Entity Fixtures: Provides consistent
FlextMetricandFlextTraceobjects for domain validation. - Service Mocks: Utilizes
Mockobjects forFlextMetricsServiceandFlextContainerto isolate business logic during testing. - Data Factories: Implements classes like
MetricsTestDataFactoryfor generating specialized data (e.g., API metrics vs. performance metrics).
Sources: tests/fixtures/README.md:37-75
Dependency Injection in Tests
Fixtures often leverage the FlextContainer to provide clean, isolated environments for every test run, preventing state leakage between test cases.
This diagram shows the relationship between core test fixtures and the dependency injection container.
Sources: tests/README.md:80-97, tests/fixtures/README.md:85-92
Testing Patterns
FLEXT Observability employs Railway-Oriented Testing, which ensures that both success and failure paths are explicitly validated. Every operation returns a result object that must be checked for success/failure status.
Sources: tests/README.md:46-51, tests/README.md:103-120
Integrated Service Testing
Integration tests bridge the gap between unit and E2E testing by validating the interaction between multiple components, such as the FlextObservabilityMasterFactory and the FlextMetricsService.
def test_metrics_service_with_factory_integration():
"""Test metrics service integration with factory."""
container = FlextContainer()
factory = FlextObservabilityMasterFactory(container)
metrics_service = FlextMetricsService(container)
# Create metric via factory
metric_result = factory.create_metric("integration_test", 42.0)
assert metric_result.success
# Process via service
record_result = metrics_service.record_metric(metric_result.data)
assert record_result.success
Sources: tests/integration/README.md:32-45
Test Configuration and Execution
The test suite is managed via pytest and configured through conftest.py. The project sets high quality gates, requiring a minimum of 95% coverage across all modules.
Coverage and Quality Standards
| Requirement | Threshold / Standard |
|---|---|
| Minimum Coverage | 95% (Global) |
| Critical Path | 100% (Core functions) |
| Pattern Compliance | Railway-Oriented Programming (r) |
| Execution Speed | Fast (<1s), Integration (<10s), E2E (<30s) |
Sources: tests/README.md:162-171, tests/unit/README.md:17-21, tests/integration/README.md:18-22
Execution Commands
Tests can be targeted by category using the following commands:
- E2E:
pytest tests/e2e/ -v - Integration:
pytest tests/integration/ -v -m integration - Unit:
pytest tests/unit/ -v - Coverage:
pytest --cov=src --cov-report=html
Sources: tests/e2e/README.md:92-100, tests/integration/README.md:73-82, tests/unit/README.md:55-63
Conclusion
The End-to-End & Fixtures system is a critical component of the FLEXT Observability quality assurance strategy. By combining high-fidelity E2E workflow simulations with a robust, containerized fixture system, the project ensures that observability data remains reliable and consistent across the entire platform lifecycle.
Sources: tests/e2e/README.md:15-21, tests/fixtures/README.md:19-25