0 Fork 0

mirror of https://github.com/kevinveenbirkenbach/computer-playbook.git synced 2026-11-08 19:56:53 +00:00

Files

T

Environment TestandClaude Opus 4.6 a2275e6991 docs(make): pass variables after target to match Bash(make*) permission

Reorders all documented and scripted `make` invocations from the
`VAR=value make target` shell-env prefix form to the make-native
`make target VAR=value` form. GNU Make auto-exports both command-line
and inherited shell-env variables to recipe shells, so the change is
purely about command-line shape: only the make-suffix form starts with
`make` and is therefore matched by the `Bash(make*)` permission entry
in .claude/settings.json, avoiding unnecessary approval prompts for
agent runs.

Adds an explicit CLAUDE.md rule with ✅/❌ examples and the underlying
reason (permission prefix match, not Makefile semantics).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

2026-04-15 12:28:44 +02:00

2.7 KiB

Raw Blame History

Integration Tests 🔗

This page is the SPOT for 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 TEST_PATTERN to scope the test run to a single file or a glob:

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

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

2.7 KiB Raw Blame History