Invariants on Ocarina — précis

Chapitre 02.04 — Invariants

Wed, 20 May 2026 00:00:00 +0000

Chapitre 02.04 — Invariants#

Sous-DSL d’Ocarina dédié à l’expression d’invariants typés et composables. Utilisé partout : par la CLI, par les POMs, par les custom_invariants/testing/ qui valident la cohérence des suites avant exécution.

Plan#

#	Fichier	Sujet
01	`01-validate-flow.md`	Le flot complet `validate(value) → assert_that → execute → raise_if_invalid` + la classe `_ValidationChain`.
02	`02-assertions.md`	Catalogue des assertions builtin (`is_str`, `is_email`, `is_positive`, `is_in`, `has_unique_elements`, `each`, `is_valid_filename`, …).
03	`03-otherwise-any-of.md`	`.otherwise(...)` et la combinaison OR via `_any_of`.
04	`04-then-chain-of-validations.md`	`.then(new_value)` et `chain_validations(...)` pour la composition.
05	`05-business-vs-framework-validator.md`	`BusinessInvariantValidator` vs `FrameworkInvariantValidator`
06	`06-invariant-errors.md`	`InvariantViolationError`, `DuplicatesError`, `AggregateInvariantViolationError`.

Le pourquoi du DSL d’invariants#

Garde-fou avant exécution. TestSuite.__init__ valide avant de lancer quoi que ce soit que les noms / IDs des tests sont uniques, que max_workers >= 1, etc.
Validation CLI. Chaque flag a son validate=lambda chain: chain.assert_that(...) dans le CliStore. Les erreurs s’agrègent et sortent en un seul message d’erreur.
Validation côté POM. Les actions de POM peuvent valider leurs paramètres (« retries doit être positif ») via validate(retries, name="retries").assert_that(is_positive).execute().raise_if_invalid().

Le Holy Book le résume :

Chapitre 02.05 — Orchestration

Wed, 20 May 2026 00:00:00 +0000

Chapitre 02.05 — Orchestration#

Chaîne Test → TestSuite → TestCampaign → TestCycle : comment chaque niveau s’articule, qui gère la parallélisation, qui gère les rejeux, qui décide du skip, et où vivent les invariants pré-exécution.

Plan#

#	Fichier	Sujet
01	`01-test.md`	La classe `Test[Driver]` — `spawn`, fragments pre/post, skip.
02	`02-test-executor.md`	`TestExecutor` — exécution d’une tentative, ordre : setup → watchers.start → chain → watchers.stop → teardown.
03	`03-test-flow-retries.md`	`TestFlow` — boucle de rejeu (1+max_retries), backoff linéaire, gestion des setup-failures.
04	`04-test-suite.md`	`TestSuite` — parallélisation avec `ThreadPoolExecutor`, filtrage IDs, garde-fous.
05	`05-saturation.md`	Saturation des workers : clonage aléatoire `[COPY N]`. Pourquoi et comment.
06	`06-test-campaign.md`	`TestCampaign` — séquence de suites, `campaign_has_failed`.
07	`07-test-cycle-modes.md`	`TestCycle` — smoke + main, modes `fail-fast` vs `wait-for-all`, `has_test_cycle_failed`.
08	`08-filter-tests-by-ids.md`	`filter_tests_by_ids` — `--only`/`--exclude`, mutex, ignore les unknown IDs.

Schéma#

            ┌────────────────────────────────────────────────┐
            │                  TestCycle                     │
            │                                                │
            │  ┌──────────────────────────────────────────┐  │
            │  │ smoke_tests_campaigns                    │  │ ◄── 1er, gate
            │  │  └─ TestCampaign                         │  │     mode : fail-fast |
            │  │      └─ TestSuite                        │  │            wait-for-all
            │  │          └─ Test                         │  │
            │  └──────────────────────────────────────────┘  │
            │                                                │
            │  ┌──────────────────────────────────────────┐  │
            │  │ campaigns (main)                         │  │ ◄── skippées si
            │  │  └─ TestCampaign                         │  │     un smoke fail
            │  │      └─ TestSuite                        │  │
            │  │          └─ Test                         │  │
            │  └──────────────────────────────────────────┘  │
            └────────────────────────────────────────────────┘

Qui fait quoi ?#

Niveau	Responsabilité unique	Concurrence	Hors périmètre
`Test`	Métadonnées + `spawn(driver, logger)`	aucune	exécution
`TestExecutor`	Une tentative	aucune	rejeu, acquisition de driver
`TestFlow`	Boucle de rejeu	aucune	parallélisation, agrégation
`TestSuite`	Parallélisation + saturation + filtrage IDs	N threads	séquence inter-suites
`TestCampaign`	Séquence de suites	suite-level	smoke vs main
`TestCycle`	Smoke + main + mode	campaign-level	bootstrap / plugins post-exec

Cette séparation stricte est délibérée : TestExecutor ne sait rien des retries, TestFlow ne sait rien de la concurrence, TestSuite ne sait rien de l’agrégation campaign-level. Chaque classe a un seul axe de responsabilité.

04.06 — Property-based testing (hypothesis)

Wed, 20 May 2026 00:00:00 +0000

04.06 — Property-based testing (`hypothesis`)#

Un seul fichier (test_invariants_properties.py), mais le pattern est intéressant : on génère des inputs et on vérifie des propriétés universelles des prédicats d’invariants.

Le concept#

hypothesis génère automatiquement des cas de test qui satisfont des contraintes données, puis vérifie qu’une propriété est vraie pour tous les cas générés. En cas d’échec, hypothesis fait du shrinking pour trouver le plus petit contre-exemple.

from hypothesis import given, strategies as st

@given(st.integers())
def test_is_positive_passes_on_positive(value):
    if value >= 0:
        is_positive(value)             # ne doit pas lever
    else:
        with pytest.raises(InvariantViolationError):
            is_positive(value)         # doit lever

→ hypothesis génère des entiers (typiquement 100 par défaut), vérifie la propriété pour chacun. Si une exception inattendue surgit, c’est un fail. Le shrinker trouve le plus petit cas qui fail (0 ? -1 ? MIN_INT ?).

Invariants on Ocarina — précis

Chapitre 02.04 — Invariants

Chapitre 02.04 — Invariants#

Plan#

Le pourquoi du DSL d’invariants#

Chapitre 02.05 — Orchestration

Chapitre 02.05 — Orchestration#

Plan#

Schéma#

Qui fait quoi ?#

04.06 — Property-based testing (hypothesis)

04.06 — Property-based testing (hypothesis)#

Le concept#

04.06 — Property-based testing (`hypothesis`)#