Module Governance Tests
Relevant source files
The following files were used as context for generating this wiki page:
Module Governance Tests define the behavioral contract for the public entry points and structural integrity of the flext-dbt-oracle-wms package. These tests ensure that the core components—specifically the Simple API and CLI service—are correctly exported, importable, and callable, maintaining the architectural boundaries required for the integration project.
The scope of these tests extends beyond simple execution to validate the "Universal Agent Engineering Core" principles, which mandate that configuration changes do not break tests and that all first-class code (including tests and examples) adheres to strict linting and typing gates.
Sources: tests/unit/test_module_governance.py:1-15, AGENTS.md:10-25, README.md:35-45
Governance Principles and Architecture
The project operates under a set of "Universal Agent Laws" that govern code quality, testing, and configuration. These laws ensure that the project remains a "continuous green" environment where every violation is fixed at its root.
Core Governance Rules
The following table summarizes the primary governance rules that the test suite enforces by construction:
| Rule ID | Rule Name | Description |
|---|---|---|
| P0 | Configuration Validation | Tests must validate config/settings changes and never hardcode current values. |
| 7 | Continuous Green | No completion is permitted while gates (Ruff, Pyright, Mypy, Pytest) are failing. |
| 19 | No Hidden Code | tests/ and scripts/ are first-class code under the same gates as src/. |
| 24 | Source-First | Changes must be based on the canonical source of truth (e.g., pyproject.toml). |
Sources: AGENTS.md:12-45, AGENTS.md:144-150
Structural Hierarchy
The project uses a lazy-loading mechanism for its test suite and public exports to optimize performance and maintain clean namespace boundaries.
This diagram illustrates how the governance tests validate the lazy-loaded public entry points of the package.
Sources: tests/init.py:45-125, tests/unit/test_module_governance.py:11-15
Implementation Details
The governance tests specifically target the visibility and accessibility of the project's primary interfaces.
Public Entrypoint Validation
The test_public_entrypoints_are_importable_and_callable function verifies that the core classes and the CLI main function are correctly exposed by the package.
class TestsFlextDbtOracleWmsModuleGovernance:
"""Behavior contract for flext_dbt_oracle_wms package exports."""
def test_public_entrypoints_are_importable_and_callable(self) -> None:
tm.that(FlextDbtOracleWms.__name__, eq="FlextDbtOracleWms")
tm.that(callable(main), eq=True)
tm.that(FlextDbtOracleWmsCliService.__name__, eq="FlextDbtOracleWmsCliService")
Sources: tests/unit/test_module_governance.py:11-15
Quality Gates and Tooling
Governance is enforced through a robust set of development dependencies and tool configurations defined in pyproject.toml.
- Linting/Formatting:
ruff,black,isort. - Type Checking:
mypy,pyright,pyrefly. - Testing Framework:
pytestwith various plugins (pytest-cov,pytest-xdist). - Security/Audit:
bandit,pip-audit.
Sources: pyproject.toml:50-120
Execution Requirements
Module governance tests must be executed through the project's canonical command surface. Direct tool invocations that bypass these guards are prohibited by universal law.
The flow demonstrates the mandatory path for validating a change before it can be considered "Done" within the governance framework.
Sources: AGENTS.md:120-130, pyproject.toml:160-165
Summary
Module Governance Tests serve as the final gatekeeper for architectural integrity in the flext-dbt-oracle-wms project. By validating that the public facade and CLI services are importable and that the project adheres to strict "Universal Agent Law," these tests ensure the library remains stable across configuration changes and collaborative development cycles.
Sources: AGENTS.md:12-15, tests/unit/test_module_governance.py:1-15