Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • crater-data crater-data
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 23
    • Issues 23
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 4
    • Merge requests 4
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • lgalga
  • crater-datacrater-data
  • Issues
  • #63

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
Edited Mar 09, 2022 by Lionel
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking