Framework de test — variables manquantes dans le contexte d'assertions et surcharge cluster/tenant impossible #8
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Contexte
En corrigeant des échecs du test summary, plusieurs aspects peu évidents (ou potentiellement des manques) du framework de test
Test/TestSetont été identifiés.1. La variable
tenantn'est pas exposée au rendu des assertionsPour un package
type: tenant, le template système utilise{{ tenant.name }}(peuplé en prod parcontext.tenant, dérivé du labelvynil.solidite.fr/tenant).Côté test, le moteur de rendu des
selector/valuedesassertsne connaît queinstance,var,defaults, … — pastenant. Toute assertion qui tente de référencer{{tenant.name}}échoue avecFailed to access variable in strict mode Some("tenant.name").En l'absence d'un label
vynil.solidite.fr/tenantsur le namespace (cas par défaut en test),tenant.nameretombe surinstance.metadata.namespace. Ce comportement de repli existe dans le code (instancetenant.rs) mais n'est documenté nulle part, et aucun exemple dans le repo ne montre le bon pattern pour ce cas.Suggestion : soit exposer
tenant(avec une valeur cohérente, dérivée comme en prod) dans le contexte de rendu des assertions pour les packagestenant, soit documenter clairement le pattern de repli (instance.namespacefait office de nom de tenant par défaut).2. La variable
valuesn'est pas exposée au rendu des assertions{{values.xxx}}dans un blocvalue:d'assertion casse avecFailed to access variable in strict mode Some("values.xxx"). Aucun test du repo n'utilise{{values.*}}dans une assertion, ce qui suggère que ce n'est simplement pas supporté — seuls{{instance.*}},{{var.*}}et{{defaults.*}}semblent valides à cet endroit.Le contournement (valeur littérale au lieu de
{{values.common_name}}) crée un couplage implicite entre le test et la valeur par défaut du package : si le défaut change, le test continuera de "passer" en testant la mauvaise valeur.Suggestion : exposer
values(les options résolues de l'instance, mêmes valeurs que celles disponibles aux templates système) au rendu des assertions — c'est probablement ce que les auteurs de tests attendent en écrivant{{values.xxx}}.3. Aucun moyen de configurer
context.cluster.hadepuis unTestUn test fixait
instance.options.ha: trueen s'attendant à déclencher le chemin HA (2 replicas + PodDisruptionBudget). Mais :hadans sonpackage.yaml(doncinstance.options.han'a aucun effet, silencieusement) ;context.cluster.haest dérivé en mode test du nombre de nœuds mockés (defaults.nodes), qui vaut["single"]par défaut →cluster.ha = false;Test/TestSet, de surcharger ce nombre de nœuds oucontext.cluster.hadirectement (pas de clécluster:/nodes:dans le schémaTest).Résultat : le test ne peut pas exercer le chemin HA qu'il prétend tester — il resterait sur
replicas: 1alors qu'il attendreplicas: 2.Suggestion : permettre de surcharger
context.cluster.ha(ou le nombre de nœuds mockés) depuis unTest/TestSet, ou clarifier si le package doit avoir sa propre optionhaplutôt que de dépendre de la capacité cluster.Résumé
Ces trois points touchent au même concept : quelles variables sont réellement disponibles dans le contexte de rendu des assertions, et comment surcharger le contexte cluster/tenant depuis un
Test. Ce n'est documenté nulle part dans le repo, et chaque "bonne pratique" applicable est une déduction du code source de l'agent plutôt qu'un pattern officiel. Une doc courte sur "ce qui est exposé où" éviterait ces allers-retours.Implémenté et soumis en PR upstream : https://github.com/sebt3/vynil/pull/228
Les trois points sont traités :
{{tenant.name}}dans les assertions —tenant.nameest maintenant exposé dans le contexte Handlebars des assertions. Pour un packagetype: tenant, il vaut par défautinstance.namespace(le même repli queinstancetenant.rsen production). Il peut être surchargé viainstance.tenant: <nom>dans la définition duTest.{{values.xxx}}et{{defaults.xxx}}dans les assertions — Les deux variables sont maintenant disponibles.defaultscontient les valeurs par défaut du schémapackage.options;valuesfusionne ces défauts avec lesinstance.optionsdu test — exactement ce que les scripts Rhai reçoivent à l'exécution.Surcharge de
context.cluster.ha— Nouveau champnodesdansVynilTestInstance. En spécifiantnodes: [master01, worker01], les objets Node sont injectés automatiquement dans la couche mock k8s.build_context.rhai::run()calcule alorsha = nodes.len() > 1de façon naturelle, sans modifier les scripts Rhai.Cinq tests unitaires couvrent les cas nominaux et les overrides.