Faire le point sur la stratégie de test & vérif globale des données
Situation actuelle :
- on fait des vérifications sur les données source dans le code de crater-data (ex : regroupements de communes). En cas d'échec cela plante
- on fait des redressements de données sources dans crater-data (pour corriger des erreurs que l'on a identifié)
- on fait des tests dans cdr sur les données résultats pour les valider
Problème :
- le code de crater-data pour le chargement des sources peu devenir complexe
- on fait des traitements similaires entre la vérif des sources et les tests sur les résultats
- les tests sur les résultats et la vérif des sources sont incomplet => faut-il les compléter tel quel ? comment rationnaliser ? quoi tester/vérifier ? et a l'inverse qu'est ce que l'on peut éviter de tester ?
- les tests sur les données cdr s'exécutent "tard". On a un feedback quand le pipeline cdr tombe (sauf si on pense a les exécuter quand on fait la MR sur c-d mais cela n'est pas automatique)
- quand on ajoute des regroupements de communes, il faut mettre a jour les tests dans cdr, c'est long et peu utile
- plus globalement, la maj des tests cdr est longue et pas pratique (bcp de constantes ou valeurs dans les tests, pas facile a mettre a jour. Serait peut etre mieux dans un fichier ? )
Décision 9/03 :
- suppression des tests cdr
- remplacés par un mécanisme dans cd qui fera
- génération de fichiers de stats au moment de l'export des fichiers résultats
- nouveau dossier tests_qualite_donnees pour faire des tests génériques sur tous les fichiers de stats (fichier expected doit etre egal à output)
- les fichiers de stat contiennent pour chaque indicateur le nb de valeur, le nb de NA, le max et le min, grouper par categorie de territoire