Ébauche de "Plan de test (non automatisé)"

[thbar]

Suite à différentes PR assez "larges" en terme d'impact dont:

• Mise à jour Elixir 1.15 -> 1.16 et Erlang 24 -> 25 #3815
• Permet de masquer des jeux de données #3826
• Correction dette technique sur les fonctions de type prédicats ("is_xyz?" -> "xyz?") #3827

Et suite à discussion avec @vdegove, je me rends compte qu'on n'a pas vraiment de "checklist" écrite pour faire un tour de l'application "raisonnable", ce qui est parfois rassurant ou utile quand on touche à des dépendances ou du code avec des impacts.

Par exemple:

• client HTTP avec une MAJ majeure et quid de tous les téléchargements
• upgrade de LiveView (qui n'est pas encore en v1.0 et qui n'est pas tout le temps super facile à tester, en tout cas où nos patterns de tests et d'implémentation ne sont pas super homogènes)
• choses qui touchent à OTP (connections SSL bas niveau, et en prime on n'a pas forcément un super monitoring là dessus)

Evidemment l'idéal est d'améliorer la couverture "effective" (= le fait que nos tests "attrapent" bien les problèmes en amont, ou que notre monitoring nous prévient bien), mais détecter certains soucis peut être compliqué (voir #3819 pour un cas récent).

Je note quelques points de l'application, on verra ce qu'on en fait, @vdegove tu peux ajouter des choses ?

• Accès au back-office et un peu tous les boutons (certains ne marchent pas sur prochainement)
• Historisation des données (et donc: comment configurer ça en local - cf MinIO par exemple ou bucket)
• Import Data Gouv réel
• Proxy (GTFS-RT, GBFS...)
• Validation à la demande
• Choses un peu exotiques du type consolidation GTFS nationale, cartes...
• "Trucs" qui appellent "Rambo" (exécution de processus hors BEAM)
• API

Voilà sans tomber dans la parano, l'idée serait d'avoir une petite liste des features "un peu délicates ou clé", qu'on puisse utiliser si on doit faire le tour.