Scénarios de test

Comment rejouer un scénario du classeur de tests (identito-vigilance et rattachement des tumeurs) sur l’instance de staging, qui sert de bac à sable. Il n’y a pas de seconde base : staging est remise à zéro, puis remplie avec les données du scénario, puis l’import du scénario est lancé comme n’importe quel import.

Ce que fait la remise à zéro

Le bouton Remettre à zéro du tableau de bord Data manager vide les patients, tumeurs, signalements, imports, fichiers, files de travail et historiques. Il conserve les comptes utilisateurs et leurs sessions, les registres et leurs membres, les paramètres de registre, les structures (FINESS) et les référentiels. Après la remise à zéro, le prochain patient est PAT-1, la prochaine tumeur TUM-<année>-1, le prochain import porte le numéro 1.

Le bouton n’apparaît que sur staging, pour un Data manager. Il refuse de s’exécuter tant qu’un traitement est en cours : attendez la fin de l’import en cours et réessayez.

Avant de commencer

• Prévenez l’autre PO : staging est le bac à sable pendant toute la campagne, et une recette ou un audit lancé en même temps verrait une base vide.
• Préparez le classeur : les référentiels, la table des patients et tumeurs avant, les signalements à importer (une feuille par type de source), la table attendue après.
• Dans le classeur, donnez à chaque patient de test un nom fait de lettres seulement et sa propre date de naissance. L’identito-vigilance ignore les chiffres et la ponctuation : PAT-TEST-1 et PAT-TEST-2 sont pour elle le même nom, et tous les signalements finiraient sur un seul patient.
• Saisissez les codes (morphologie 8140/3, FINESS) dans des cellules au format Texte : Excel transforme sinon 8140/6 en date.

Déroulé d’un scénario

1. Remettre à zéro depuis le tableau de bord (tapez reset pour confirmer).

2. Produire les fichiers du scénario avec une session Claude Code ouverte sur le dépôt, avec ce message :

   Lis docs/agents/sandbox-scenarios.md et produis les fichiers du classeur <chemin du fichier .xlsx>, scénarios <n à m>. Mon e-mail est <e-mail>, mon registre <code registre>. Je les passe sur staging.

   La session relit le classeur et signale ce qui l’empêcherait de passer (identités confondues, champ obligatoire absent, code abîmé par Excel, scénario sans signalement) ; elle corrige ses fichiers et liste chaque écart. Reportez ces écarts dans le classeur. Elle rend des fichiers numérotés dans l’ordre de passage :

   • 1-avant-signalements-<type>.csv : tout ce qu’un import sait produire (patients, signalements, tumeurs rattachées) ;
   • 2-avant.sql : ce que seul un ARC fait (coder une tumeur, valider un rattachement, exclure un signalement) ;
   • 3-…, 4-… : un scenario-<type>.csv par type de source ;
   • attendu.sql : la comparaison finale.

   Si la feuille décrit un état qu’aucun import ni geste ARC ne peut produire, la session le dit : c’est la feuille qu’il faut revoir.

3. Importer chaque avant-signalements-<type>.csv depuis l’écran Imports, dans l’ordre des numéros, et attendre la fin de l’intégration de chacun avant le suivant.

4. Appliquer avant.sql dans la console SQL de la Drizzle Gateway (la connexion staging). S’il s’arrête sur une erreur, rien n’est appliqué : un import avant manque ou a été passé dans le désordre, reprenez à l’étape 1. Sinon la requête de contrôle finale doit correspondre à la table « avant » de la feuille.

5. Importer chaque fichier scenario-<type>.csv, dans l’ordre des numéros, en attendant la fin de l’intégration de chacun.

6. Lire l’onglet Données de chaque import de scénario ligne à ligne contre la table « après » : impact patient, raison identito, tumeurs, raison de rattachement. Notez le verdict de chaque ligne dans le classeur. attendu.sql, exécuté dans la console, en donne un récapitulatif par patient (OK/KO, les KO en tête) : un KO se vérifie dans l’onglet Données avant d’être noté.

7. Enchaînez les scénarios en reprenant à l’étape 1. Quand la campagne est finie, le jeu de données de démonstration se restaure avec l’action GitHub Reseed staging DB.

Pour un scénario de rattachement qui part de patients ayant déjà des tumeurs, chaque patient garde un signalement exclu venu de l’import avant : il ne sert qu’à créer le patient, le rattachement ne le traite jamais, et il ne compte pas dans les résultats.

Première utilisation de la gateway

La console SQL de la Drizzle Gateway exécute du SQL et importe des fichiers .sql. À la première campagne, vérifiez une fois qu’elle exécute un script entier en un seul envoi : collez un avant.sql d’une trentaine d’instructions et contrôlez que la requête finale rend les comptes attendus. Si elle n’exécute qu’une instruction à la fois, passez par l’import de fichier .sql.

Deux conditions côté infrastructure, tenues par l’équipe de développement : la connexion de la gateway sur staging utilise le rôle propriétaire de la base (sinon le SQL est refusé en lecture seule), et la gateway est arrêtée entre deux campagnes.