Test Stubs & Mocking System
Relevant source files
The following files were used as context for generating this wiki page:
The Test Stubs & Mocking System in flext-target-oracle-oic provides a structured framework for isolating components during testing. It primarily employs "Dummy" implementations and "Composition Inheritance" to extend production models, protocols, and settings with test-specific behaviors. This architecture ensures that unit tests can validate logic without requiring active Oracle Integration Cloud (OIC) instances, while simultaneously adhering to strict engineering laws regarding code quality and SSOT (Single Source of Truth).
The system is designed around the Universal Agent Law, which strictly forbids the use of stubs or fakes to "make a gate pass" in production-adjacent code, mandating instead that stubs be used strictly within the test suite boundaries to facilitate isolation and dependency injection.
Sources: AGENTS.md:16-40, tests/models.py:15-25, tests/unit/test_target.py:30-40
Architecture and Components
The testing infrastructure is organized into specialized modules that mirror the source code structure, prefixed with TestsFlextTargetOracleOic. This approach utilizes a shared MRO (Method Resolution Order) to combine production logic with test utilities.
Composition Inheritance Pattern
Test models and protocols utilize a dual-inheritance strategy. They inherit from both the generic flext_tests infrastructure and the specific domain models of the OIC target.
The diagram above illustrates how the test models merge infrastructure-level test fixtures with domain-specific OIC models.
Sources: tests/models.py:17-36, tests/protocols.py:17-30
Test Stub Classes
The system includes minimal implementations of core Singer SDK classes to facilitate testing of Sinks and Targets without full initialization overhead.
| Class | Purpose | Source |
|---|---|---|
DummySingerTarget | Minimal Singer target implementation for validating sink mappings and configuration schemas. | tests/unit/test_target.py:34-41 |
DummySingerTargetE2E | Extended dummy target used for end-to-end sink processing path validation. | tests/unit/test_e2e_sinks.py:30-35 |
AuthTestSettings | A specialized settings stub used to test OAuth2 authenticator payload construction. | tests/unit/test_target.py:27-31 |
Mocking Logic and Implementation
The project utilizes the unittest.mock library selectively to intercept external API calls, particularly for authentication workflows where real network traffic must be avoided in unit tests.
Authenticator Mocking
To test the Authenticator without an OIC identity provider, the system patches flext_api.FlextApi.post to return a controlled result_type containing a Mock response.
This flow demonstrates the interception of the OAuth2 token request to validate the Authenticator's error handling logic.
Sources: tests/unit/test_target.py:105-125, tests/utilities.py:15-25
Governance and Constraints
Testing stubs are subject to strict module governance to prevent "leaky abstractions" where test code might influence production behavior.
- Zero-Tolerance Policy: Rule 1 of the Universal Agent Law forbids using stubs or fakes to bypass failing gates. If a failure appears in the flow, it must be fixed at the root cause rather than suppressed with a fake.
- Dependency Injection: The system mandates that collaborators (like the Authenticator) be injected rather than hard-wired, allowing for the substitution of stubs during testing.
- Function Isolation: Top-level functions in test modules are restricted. For example,
cli.pyis only allowed to have amainentry point, as enforced by constant definitions.
Sources: AGENTS.md:18-24, AGENTS.md:88-92, tests/constants.py:31-38
Test Constants and Protocols
The mocking system relies on a central repository of constants and protocols to define the state of the "mocked" environment.
| Component | Description | Source |
|---|---|---|
p.Tests.Docker | Protocol definitions for tests requiring containerized environments. | tests/protocols.py:25-28 |
c.TargetOracleOic.Tests.DEFAULT_PROPERTIES | A standardized JSON schema used to initialize dummy targets (e.g., {"id": {"type": "string"}}). | tests/constants.py:36-38 |
PROJECT_ROOT_PARENT_DEPTH | Constant defining the filesystem traversal depth for locating source modules during governance checks. | tests/constants.py:31-33 |
Sources: tests/constants.py:18-40, tests/protocols.py:15-35
Summary
The Test Stubs & Mocking System provides a robust, isolated environment for verifying the OIC target's logic. By leveraging composition inheritance and strict dummy implementations, the suite maintains high coverage of sink operations and authentication flows while strictly adhering to the project's "Zero-Tolerance" engineering laws against temporary workarounds or bypasses.
Sources: AGENTS.md:43-50, tests/unit/test_e2e_sinks.py:40-60