Stratégie de tests — CVN-N014-ED-S03 (cleanup large-data borné)¶
Périmètre — pas de code, donc pas de test unitaire¶
S03 ne modifie aucun code applicatif : c'est une constatation d'inventaire (vide) + une action ops (appliquer la lifecycle xcom/ héritée de S01) + des décisions (A(ii) différé, enforcement→S04). Il n'y a donc pas de test unitaire à écrire — il n'y a rien à exécuter.
La « vérification » de S03 prend deux formes auditables, qui tiennent lieu de tests :
| Vérification | Méthode | Preuve |
|---|---|---|
| Inventaire vide | git grep des patterns large-data (np.savez/upload_fileobj/put_object/to_parquet/to_pickle//tmp/Path/non-JSON-XCom) sur dags/** + src/commun/finetune/**, avec critères de classification (non-conformant / conformant / faux-positif) |
plan §0bis — table de classement reproductible |
| Règle single-pod | un usage /tmp est conformant uniquement si producteur+consommateur même pod — appliquée à s18 (conforme) vs s43 (était cassé : pods différents) |
plan §0bis (règle explicite) |
Lifecycle xcom/ appliquée |
get-bucket-lifecycle-configuration in-pod |
règle xcom-objectstorage-7d-retention active (prefix xcom/, 7j) à côté de cleanup-old-artifacts + s43-predictions-7d-retention |
Régression¶
La prévention des réintroductions (un nouveau DAG qui re-bricolerait un transport large-data cross-pod) n'est pas un test runtime de S03 : elle est transférée à S04 (review gate normatif). Recos comité plan_review : un check CI « single-pod » + automatiser le gate S04 (forward-looking).
Pattern de référence¶
Le test de référence pour un futur transport large-data cross-pod = la stratégie de tests S02 (test_strategy S02) : round-trip + schéma fail-loud (unit) + smoke cross-pod réel (acceptation). Un 2ᵉ consumer (qui déclencherait A(ii)) la reprendra.