Test Fixtures & Configurations

Relevant source files

The following files were used as context for generating this wiki page:

• tests/README.md
• tests/unit/README.md
• tests/unit/test_smoke.py
• tests/init.py
• pyproject.toml
• examples/01_basic_usage.py

The test fixtures and configurations in the flext-api project provide a standardized environment for validating high-performance REST API components. The system is designed to support multiple testing tiers, including unit, integration, and end-to-end (e2e) tests, using a combination of shared configurations, mock utilities, and lazy-loading mechanisms.

This infrastructure ensures that core components such as the FlextApiClient, query builders, and Pydantic models are validated against strict performance and type-safety standards. The configuration system relies heavily on pyproject.toml for tool settings and tests/conftest.py for shared test data and fixtures.

Sources: tests/README.md:1-12, tests/unit/README.md:1-10, pyproject.toml:390-410

Test Suite Architecture

The testing architecture is organized hierarchically to separate concerns between fast isolated logic checks and slower external service integrations.

Directory Structure and Categories

The tests/ directory is structured to provide a clear separation between configuration, utilities, and actual test implementation.

Directory	Purpose	Key Components
fixtures/	Test data and assets	Static JSON/Binary data
test_helpers/	Shared utilities	Custom assertions, mock factories
unit/	Fast isolated tests	Core logic, exception handling
integration/	Real service tests	HTTP clients, DB connections
e2e/	Workflow validation	Full request/response cycles
benchmarks/	Performance testing	Execution time, memory profiling

Sources: tests/README.md:14-25, tests/unit/README.md:15-32

Dependency Management

Testing dependencies are managed via the [project.optional-dependencies] section in pyproject.toml. The test group includes specialized tools like factory-boy for fixture generation, hypothesis for property-based testing, and various pytest plugins for coverage and benchmarking.

Sources: pyproject.toml:68-142

Test Configuration and Markers

The project uses pytest markers to categorize and filter test execution. These markers are defined in the tool.pytest.ini_options section.

Marker Definitions

The diagram shows the logical categorization of tests using markers to control execution flow.
Sources: pyproject.toml:414-424

Execution Standards

Unit tests must adhere to the following standards:

• Fast Execution: Less than 100ms per test.
• Isolation: Proper use of mocking to prevent side effects.
• AAA Pattern: Structure tests by Arrange, Act, Assert.
• Strict Markers: Use -m "not slow" or specific markers for targeted runs.

Sources: tests/unit/README.md:44-50, tests/README.md:52-60

Functional Smoke Tests

Smoke tests validate that key facades and constants are usable at runtime. These tests are located in tests/unit/test_smoke.py.

Validation Domains

The smoke test suite covers several critical areas:

1. Enum Integrity: Ensures Method, Status, and ContentType resolve to correct values (e.g., c.Api.Method.GET == "GET").
2. Model Defaults: Validates that HttpRequest correctly populates default headers and methods.
3. Boundary Checks: Verifies HTTP status code boundaries (100-599).
4. Client Initialization: Confirms that FlextApiClient correctly consumes FlextApiSettings via keyword arguments.

Sources: tests/unit/test_smoke.py:27-55, tests/unit/test_smoke.py:102-115

Code Snippet: Setting Validation

def test_api_client_uses_keyword_settings(self) -> None:
    """FlextApiClient accepts a settings model through the public settings input."""
    settings = FlextApiSettings(base_url="https://service.example", timeout=9.5)
    client = FlextApiClient(settings=settings)
    assert client.base_url == "https://service.example"
    assert abs(client.timeout - 9.5) < 1e-9

Sources: tests/unit/test_smoke.py:102-108

Lazy-Loading and Test Imports

To maintain high performance and avoid circular dependencies, the tests package implements a lazy-loading mechanism. The tests/__init__.py file uses flext_core.lazy utilities to map imports.

Import Mapping Workflow

The sequence diagram illustrates how test utilities like constants and models are loaded only when accessed.
Sources: tests/init.py:42-75

Coverage and Quality Gates

The project enforces strict quality gates through coverage reporting and linting.

• Coverage Threshold: The tool.coverage.report section sets fail_under = 25 and excludes code paths like if TYPE_CHECKING:.
• Linting: Ruff is used with ALL rules selected, but specific ignores are applied to tests (e.g., S101 for asserts, ARG001 for unused arguments in fixtures).
• Type Checking: Pyright and MyPy are configured to ignore tests/fixtures but strictly check src and tests directories.

Sources: pyproject.toml:153-160, pyproject.toml:502-530, pyproject.toml:600-650

Conclusion

The "Test Fixtures & Configurations" system in flext-api provides a robust foundation for maintaining code quality. By utilizing a hierarchical directory structure, strict pytest markers, and a lazy-loading import system, the project balances fast unit testing with comprehensive workflow validation. The configuration managed via pyproject.toml ensures that environment settings and quality gates remain consistent across development and CI/CD pipelines.