0 Fork 0

mirror of https://github.com/kevinveenbirkenbach/computer-playbook.git synced 2026-11-06 19:01:54 +00:00

Files

T

kevinveenbirkenbachandClaude Opus 4.7 9a578952c3 feat(env): SPOT env-pipeline + INFINITO_* namespace

Replace 8 bash env modules with a single Python generator
(cli.meta.env) that materialises env/static.env + runtime context
into a gitignored .env. Each variable lives in its own handler
under utils/env/handlers/; defaults carry inline one-line `# ...`
comments.

Rename to the INFINITO_* schema:
- workflow inputs: APPS, SERVICES_DISABLED, CMD, DEBUG, WHITELIST,
  BUNDLES, FULL_CYCLE, VARIANT, RUN_FLAGS, LIMIT_HOST, PARALLEL
- inventory: INVENTORY_DIR / INVENTORY_FILE / HOST_VARS_FILE,
  PW_FILE -> INVENTORY_PASSWORD_FILE
- venv: VENV_BASE / VENV_FALLBACK / VENV_NAME
- new SPOT defaults: COMPILE_SILENCE, CONTAINER_NO_CA,
  WAIT_HEALTH_TIMEOUT_S, PACKAGE_CACHE_FRONTEND_INIT_IMAGE,
  promoted IMAGE_TAG from GHA-only to general passthrough

compose.yml hardening:
- inline \${VAR:-default} removed; strict \${VAR:?...} everywhere
- new integration lint blocks regressions

Tooling:
- scripts/install/all.sh owns the stamp-file install logic
  (Makefile target delegates)
- scripts/meta/env/load.sh is the single shell entry point;
  8 bash modules deleted
- new shell lint: no INFINITO_* defaults outside env/static.env

Tests:
- 93 new unit tests for utils/env/{builder,parser,runtime,writer}
- restructure tests/lint into repository/ (file-content rules) vs
  filesystem/{shell,python,env}/ (filesystem-shape rules)
- drift + smoke integration tests against the generator

Docs:
- variables.md is now a pointer; per-variable docs live next to
  the key in env/static.env / env/ci.env
- compose.yml.md drops the Default column

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-20 20:40:34 +02:00

2.8 KiB

Raw Blame History

Integration Tests 🔗

This page covers integration testing requirements, framework, and structure. Run integration tests with make test-integration.

Framework 🧰

You MUST use Python unittest as the test framework.
Tests that verify real runtime component interactions MUST live under tests/integration/.
Tests that statically analyze Ansible config or task YAML files without exercising runtime boundaries MUST live under tests/lint/ansible/ instead.

When to Write ✍️

You MUST add or update integration tests for every *.py file you touch when the change affects behavior across module or runtime boundaries.
Write an integration test when the behavior you are verifying depends on two or more components working together at runtime. For example, verify a lookup plugin reading from real group_vars or a filter interacting with an Ansible variable structure.
Write a lint test under tests/lint/ansible/ when the check only inspects static YAML structure, config keys, or comment annotations without executing any code.

Requirements 📋

You MUST NOT write unit tests for integration test logic. Integration tests verify real runtime boundaries; extracting that logic into unit tests defeats the purpose and duplicates coverage. The integration test itself is the specification.
You MUST NOT mock collaborators that are part of the integration boundary being tested. The point is to verify real interaction.
You MUST NOT write tests that only assert a file contains a string.
You MUST NOT write tests only for non-executable files such as .yml or .j2. Test the behavior that consumes them.
You SHOULD keep each test focused on one integration boundary.
You SHOULD test realistic inputs that match what Ansible would pass at runtime.
You MAY use unittest.mock to stub out external services or filesystem state that is genuinely outside the integration scope.

How to Create 🛠️

Identify the integration boundary (e.g. lookup plugin + group_vars variable loading).
Decide whether the test exercises a real runtime interaction (tests/integration/) or only inspects static YAML structure (tests/lint/ansible/).
Create the matching test file under the correct directory if it does not exist.
Subclass unittest.TestCase.
Use realistic inputs. Build hypotheses about cross-component behavior before writing assertions.
Run make test-integration (or make test-lint for lint tests) and verify all tests pass.

Running Specific Tests 🏃

Use INFINITO_TEST_PATTERN to scope the test run to a single file or a glob:

# Run a single integration test file
make test-integration INFINITO_TEST_PATTERN=test_my_module.py

# Run all files matching a prefix
make test-integration INFINITO_TEST_PATTERN=test_applications*.py

2.8 KiB Raw Blame History