Testing Strategy
Relevant source files
The following files were used as context for generating this wiki page:
The testing strategy for flext-web is built on a foundation of comprehensive coverage, strict type safety, and automated quality gates. It ensures that all platform components maintain an enterprise-grade standard, specifically targeting 85%+ coverage for foundation libraries and 75%+ for applications. The strategy is centered on the canonical public facade from flext_web import web, ensuring that tests exercise real public usage rather than private internals.
Sources: guides/testing.md:46-52, tests/README.md:1-5
Testing Hierarchy and Categories
The project employs a hierarchical test structure organized within the tests/ directory. This structure separates concerns based on the scope and isolation level of the tests.
This diagram represents the physical and logical organization of the testing suite.
Sources: guides/testing.md:58-65
Unit Tests
Unit tests focus on individual functions and classes in isolation. They are designed to be fast and use mocks for external dependencies to ensure reliability.
Sources: guides/testing.md:70-73
Integration Tests
Integration tests validate the interaction between multiple components or services, often involving the dependency injection container (FlextContainer). In flext-web, integration tests must validate real public usage through the web facade.
Sources: guides/testing.md:105-110, tests/README.md:20-22
End-to-End (E2E) Tests
E2E tests verify complete user scenarios and workflows, such as full data migrations or API lifecycles, often involving file system operations or temporary directory setups.
Sources: guides/testing.md:135-140
Quality Gates and Standards
flext-web enforces quality through "Quality Gates"—a set of mandatory checks that must pass before code is considered complete.
| Category | Requirement | Tool |
|---|---|---|
| Coverage | 85%+ (Core), 75%+ (Apps) | pytest-cov |
| Type Safety | Zero Errors (Strict Mode) | pyrefly / mypy |
| Linting | Zero Violations | ruff |
| Security | Automated Scanning | bandit |
Sources: guides/testing.md:46-52, guides/development.md:155-170
Skill Validation Pattern
Automation "skills" are validated using a generic runner that checks for invariant policies, such as strict typing or Pydantic v2 compliance.
python3 scripts/core/skill_validate.py --skill flext-strict-typing
Sources: guides/skill-automation-pattern.md:32-40
Execution Workflow
Testing is primarily driven by make targets and pytest markers. This allows developers to run specific subsets of tests based on the development phase.
The workflow sequence for running standard test suites and generating feedback.
Sources: guides/testing.md:183-195, guides/development.md:126-135
Test Markers
Standard pytest markers used in the project:
@pytest.mark.unit: Fast, isolated tests.@pytest.mark.integration: Component interactions.@pytest.mark.e2e: Full system workflows.@pytest.mark.slow: Performance or load testing.
Sources: guides/testing.md:162-181
Implementation Patterns
Railway-Oriented Assertions
Tests are designed to handle the Result (r) pattern used throughout the codebase. Assertions check for .success or .failure status before unwrapping data.
def test_process_valid_data(self):
"""Test processing valid data using Result pattern."""
result = process_data({"key": "value"})
assert result.success
assert result.unwrap().key == "value"
Sources: guides/development.md:143-152, guides/testing.md:82-90
Dependency Mocking
For unit testing external services, the project utilizes unittest.mock to simulate successful or failed responses without invoking real network or file operations.
Sources: guides/testing.md:275-285
Configuration Reference
Testing behavior is defined in pyproject.toml under [tool.pytest.ini_options].
| Setting | Value | Description |
|---|---|---|
addopts | --strict-markers --timeout=10 | Enforces marker definitions and test timeouts. |
testpaths | src, tests, examples | Directories scanned for tests. |
fail_under | 25 (minimum baseline) | Coverage threshold for CI failure. |
Sources: pyproject.toml:500-525, pyproject.toml:135-140
Conclusion
The flext-web testing strategy ensures stability by combining traditional test levels (Unit, Integration, E2E) with modern automation gates. By enforcing high coverage thresholds and zero-tolerance for type errors, the strategy guarantees that the platform's public facade remains reliable for all integrating applications.
Sources: guides/testing.md:46-52, tests/README.md:35-40