Unit & Integration Testing Strategy
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
The testing strategy for the FLEXT Tap Oracle WMS project is designed to ensure Singer protocol compliance and seamless integration with the FLEXT ecosystem. The strategy is structured into three primary tiers: Unit Testing for isolated component logic, Integration Testing for component interactions, and End-to-End (E2E) testing for full user workflows. A significant portion of the strategy focuses on eliminating external dependencies through comprehensive mocking to ensure reliability and speed in CI/CD environments.
Sources: tests/README.md:15-19, tests/unit/README.md:21-23
Unit Testing Strategy
Unit tests focus on validating individual components in total isolation. These tests utilize extensive mocking of external services, network calls, file systems, and environment variables to ensure deterministic results and sub-second execution times.
Sources: tests/unit/README.md:21-23, tests/unit/README.md:200-205
Core Unit Test Components
The unit testing suite covers several critical functional areas of the tap:
| Component | Test File | Focus Area |
|---|---|---|
| Authentication | test_auth_comprehensive.py | Header generation, credential validation, and error handling. |
| WMS Client | test_client_comprehensive.py | HTTP request/response handling and recovery mechanisms. |
| Configuration | test_config.py, test_config_mapper_comprehensive.py | Model validation, type conversion, and default value mapping. |
| Discovery | test_entity_discovery_comprehensive.py | Metadata extraction and Singer schema generation. |
| Validation | test_critical_validation_comprehensive.py | Environment check completeness and business rule enforcement. |
Sources: tests/unit/README.md:31-75
Mock Usage Pattern
To maintain isolation, the project employs standardized pytest fixtures for mocking the WMS client and API responses.
The diagram shows how unit tests interact with mocked dependencies instead of live services.
Sources: tests/unit/README.md:104-122, tests/unit/README.md:214-230
Integration Testing Strategy
Integration tests validate the interaction between multiple internal components (e.g., Tap ↔ Stream or Authentication ↔ Client). Currently, many integration tests are disabled due to live WMS dependencies, but the strategy involves re-enabling them using a "Mock WMS Server" approach.
Sources: tests/integration/README.md:21-25, tests/README.md:106-112
Component Interaction Logic
Integration tests verify the "chain" of operations within the tap. For example, the configuration validation chain ensures that settings are correctly loaded, mapped, and then validated against business rules.
Sequence of the configuration validation integration workflow.
Sources: tests/integration/README.md:76-92
Planned Integration Scenarios
The integration strategy targets several high-level flows:
- Discovery ↔ Schema: Verifying that discovered entity metadata correctly transforms into Singer schemas.
- ETL Flow: Testing the complete cycle of discovery, stream selection, and record extraction.
- Resilience: Testing how the client handles network failures and retries using backoff logic.
Sources: tests/integration/README.md:65-74, tests/integration/README.md:94-118, tests/integration/README.md:255-271
Testing Execution and Quality Standards
The project defines strict quality gates and execution patterns managed through make commands.
Execution Commands
| Level | Command | Purpose |
|---|---|---|
| Unit | make test-unit | Runs all isolated logic tests. |
| Fast | make test-fast | Runs tests excluding slow/integration markers. |
| Coverage | make test | Runs tests with full HTML coverage reporting. |
| Integration | make test-integration | Runs interaction tests (requires mock server). |
Sources: tests/unit/README.md:86-97, tests/README.md:83-93
Quality Requirements
The following standards are enforced for all tests:
- Line Coverage: Minimum 90% coverage for all components (Target: 95%).
- Naming Convention:
test_[component]_[scenario]_[expected_outcome]. - Performance: Total suite should complete in under 2 minutes; unit tests < 100ms each.
- Deterministic: Tests must be reliable and pass consistently without external network access.
Sources: tests/unit/README.md:162-166, tests/unit/README.md:175-188, tests/README.md:183-191
Conclusion
The Unit & Integration Testing Strategy for FLEXT Tap Oracle WMS provides a robust framework for validating a complex Singer tap. By prioritizing isolation through mocks and structured integration tiers, the project ensures that code changes can be verified quickly and reliably. The ongoing focus remains on re-enabling integration and E2E suites through a comprehensive mock WMS infrastructure to achieve 100% production confidence.
Sources: tests/README.md:224-227, tests/integration/README.md:296-302