Il me semble qu'on ne cherche pas à remplir une map : $data.SetInMap (printf "average-%s-nonapplicable-t" $type)

Mais à obtenir la liste des critères testés dans tous les audits réalisés. On veut un dictionnaire contenant la valeur "all" en prenant en compte le fait que dans certains cas : tous les critères peuvent être soit conformes, soit non conformes, soit non applicables. Des cas assez particuliers.

Utiliser merge dans l'absolue n'est peut être pas la bonne solution (car il ne supporte pas les valeurs vides), il serait possible de créer juste un tableau (array) avec tous les critères. Mais à revoir en détail en reprenant du code en amont.

Voir si ce code corrige :

{{ $dict1 = (dict
    "pourcentage"              ($data.Get (printf "average-%s-pourcentage"     $type))
    "pourcentage100"           ($data.Get (printf "average-%s-pourcentage-100" $type))
    "pourcentage80"            ($data.Get (printf "average-%s-pourcentage-80"  $type))
    "pourcentage50"            ($data.Get (printf "average-%s-pourcentage-50"  $type))
    "pourcentage30"            ($data.Get (printf "average-%s-pourcentage-30"  $type))
    "pourcentage00"            ($data.Get (printf "average-%s-pourcentage-00"  $type))
    "conforme"                 ($data.Get (printf "average-%s-conforme"        $type))
    "nonconforme"              ($data.Get (printf "average-%s-nonconforme"     $type))
    "nonapplicable"            ($data.Get (printf "average-%s-nonapplicable"   $type))
    "all"                      ($data.Get (printf "average-%s-conforme"        $type))
  ) }}
  {{ if and ($data.Get (printf "average-%s-conforme" $type)) ($data.Get (printf "average-%s-nonconforme" $type)) }}
    {{ $dict1 = merge $dict1 (dict "all" (merge ($data.Get (printf "average-%s-conforme" $type)) ($data.Get (printf "average-%s-nonconforme" $type)))) }}
  {{ end }}
  {{ if ($data.Get (printf "average-%s-nonapplicable" $type)) }}
    {{ $dict1 = merge $dict1 (dict "all" ((merge (merge ($data.Get (printf "average-%s-conforme" $type)) ($data.Get (printf "average-%s-nonconforme" $type))) ($data.Get (printf "average-%s-nonapplicable" $type)))))}}
  {{ end }}
  {{ if and ($data.Get (printf "average-%s-nonapplicable" $type)) (not (and ($data.Get (printf "average-%s-conforme" $type)) ($data.Get (printf "average-%s-nonconforme" $type)))) }}
    {{ $dict1 = merge $dict1 (dict "all" ($data.Get (printf "average-%s-nonapplicable" $type))) }}
  {{ end }}
  {{ if and ($data.Get (printf "average-%s-nonconforme" $type)) (not (and ($data.Get (printf "average-%s-conforme" $type)) ($data.Get (printf "average-%s-nonapplicable" $type)))) }}
    {{ $dict1 = merge $dict1 (dict "all" ($data.Get (printf "average-%s-nonconforme" $type))) }}
  {{ end }}

merci @bertrandkeller oui ça fonctionne !

Je me demande si on pourrait écrire un test automatisé pour vérifier certains de ces comportements un peu pointus.

Tu penses à quoi ?

Pour information. Le partial "Aggregate" fait tous les calculs. On pourrait l'appeler une seule fois dans le Header.
L'idée générale serait d'uniformiser les calculs, donc les types de fonction de fonction de calculs,… donc les référentiels et leurs fichier d'audit : c'est un objectif que j'ai.

Ainsi, tu pourrais avoir des éléments (sondes) à certains endroits pour vérifier des valeurs, indépendamment du type d'audit.
Ça simplifierait les devs et les évolutions. Avoir plusieurs référentiels a d'ailleurs permis de refondre une partie des partials.

Tu penses à quoi ?

Pour information. Le partial "Aggregate" fait tous les calculs. On pourrait l'appeler une seule fois dans le Header. L'idée générale serait d'uniformiser les calculs, donc les types de fonction de fonction de calculs,… donc les référentiels et leurs fichier d'audit : c'est un objectif que j'ai.

Ainsi, tu pourrais avoir des éléments (sondes) à certains endroits pour vérifier des valeurs, indépendamment du type d'audit. Ça simplifierait les devs et les évolutions. Avoir plusieurs référentiels a d'ailleurs permis de refondre une partie des partials.

Comme tu le dis, le partial aggregate a l'air de faire surtout de la logique de calculs sans contenir beaucoup de présentation. C'est en général de bons candidats pour tester unitairement.

L'idée serait d'appliquer ce partial sur des jeux de données de test. Et vérifier que ce qui est généré est conforme à ce qu'on attend.

Edit:

Après reflexion, quelque chose de simple dans un premier temps serait probablement de faire un dépôt Git avec des projets d'exemples qui représentent un certain nombre de combinaisons possibles dans les csv.

Par ex. le cas suivant ne fonctionne pas actuellement :

"Thématiques","Critères","Home","Infolettre"
"1","1","nt","nt"
"1","2","nt","nt"

Oui !

C'est ce que je n'ai pas fait. J'ai plusieurs jeux de données. C'est possible de créer plusieurs dépôts, voire 1 seul dépôt. Et de lancer des CI à chaque push de master (ou créer une vraie branche de dev) ou de montée en version.

Avec Hugo, tu peux faire des partials qui rendent des valeurs. Tu peux donc rendre des objets. Que tu vas exploiter où tu en as envie sur le site. Ils rendent plus facile la création d'un JSON.

Ensuite, tu peux créer des {{ errorf "mon erreur" }}, dans le code. Mais j'hésite encore car je ne veux pas qu'une erreur empêche une personne de lancer le serveur. Tu as aussi --panicOnWarning qui stoppe pour le moindre Warning. Pratique pour supprimer tous les petites erreurs de code.

Un dépôt qui pourrait s'appeler frago-acceptance ou un truc du genre.

Je pense qu'il est assez pratique de vérifier sur le contenu généré.
Ça évite de trop dépendre de la technologie qui génère le contenu.

J'aime bien l'idée de tester sur le contenu json.

L'approche "approval testing" s'y prête bien.

Un peu comme dans cette vidéo d'@emilybache : If Someone Was Doing Test-Driven Development, How Would You Tell?