Vérifier avant une vague
L'inscription est ouverte au public, et la diffusion s'élargit par petites vagues (dossier vision). Avant chaque vague, on vérifie sur le site déployé que la recherche, le journal, les signalements et la récupération après erreur tiennent, critère par critère (A01 à A12). On élargit seulement si rien n'échoue et qu'aucun problème bloquant ne reste ouvert. La date ne compte pas.
La vérification se fait en trois temps :
- les tests automatiques de la vague;
- les vérifications à la main, que les tests ne savent pas faire;
- la revue des problèmes observés depuis la vague précédente.
Le résultat va dans Plane (voir Noter le résultat).
Les comptes de vérification
Les tests se connectent avec deux comptes Keycloak, verif-a et verif-b, qui ont un mot de passe. Ce sont les seuls. Les vraies personnes se connectent par Google ou Apple, et l'app envoie toujours kc_idp_hint à Keycloak, qui saute alors son propre formulaire. Les tests appellent /bff/login sans fournisseur et arrivent sur ce formulaire. Keycloak bloque un compte quelques minutes après 10 mots de passe faux (bruteForceProtected dans realm.yaml). Les comptes n'ont aucun rôle, et surtout pas moderation.
scripts/comptes-test.sh creer
Le script crée les comptes s'ils manquent, leur donne un nouveau mot de passe de 40 caractères, et range ce mot de passe dans le trousseau macOS (musiqud-verif-a, musiqud-verif-b). Il passe par deploy/k8s/k3s/distant.sh, donc il faut un accès SSH à themachine. Le relancer change les mots de passe, ce qu'il faut faire aussi si l'un d'eux a fuité. Le compose local utilise le même Keycloak, et donc les mêmes comptes.
Dans Musiqud, les deux comptes sont publics et s'appellent « Vérif A » et « Vérif B ». Avant et après chaque test, le BFF les remet à zéro : journal, Top 5 et collections vides, profil public, aucun abonnement ni blocage entre eux. Entre deux vagues, il ne reste d'eux que les signalements, que la modération ferme.
1. Les tests automatiques
tests/run.sh --vague # contre https://app.listner.io
tests/run.sh --vague --local # contre le compose, sur le port 8080 seulement (celui que déclare le realm)
Les tests sont dans tests/e2e/vague/. Le projet vague-connexion connecte les deux comptes par le formulaire de Keycloak, les inscrit la première fois et garde leur session dans tests/e2e/.auth/ (ignoré par git). Le projet vague vient ensuite, sans rien de simulé. La recherche interroge le miroir de MusicBrainz, et les écritures vont dans la vraie base. Ils partagent les deux comptes, donc ils passent un par un, en deux minutes environ. Le tests/run.sh habituel ne les lance pas.
| Critère | Ce que les tests vérifient | Fichier |
|---|---|---|
| A01 Recherche | Chaque filtre (albums, EP, singles, chansons) ne montre que son type, et chaque résultat le dit. Ouvrir un résultat puis revenir garde les mots, le filtre et la position. | recherche.spec.ts |
| A02 Écoute simple | Une écoute sans note ni critique se retrouve à la date choisie dans le journal. | journal.spec.ts |
| A03 Notation | Choisir 3,5 affiche « 3,5 sur 5 » sur la fiche et dans le journal. Retirer la note garde l'écoute. Une modification abandonnée ne paraît ni dans le journal ni sur le profil. | journal.spec.ts |
| A04 Réécoute | Deux écoutes à des dates différentes restent deux. Un double clic sur Enregistrer n'en crée qu'une. | journal.spec.ts |
| A05 Confidentialité | Une écoute privée ne paraît pas pour l'autre compte ni sans compte : profil, accueil, critiques de la fiche. Elle ne change pas la moyenne. Une écoute publique sert de témoin. | confidentialite.spec.ts |
| A06 Accueil | Sans abonnement, l'accueil montre les critiques de la communauté et mène vers une fiche. Une fois abonné, l'activité publique de l'autre compte paraît sous Abonnements. | accueil.spec.ts |
| A07 Top 5 | Cinq albums sans doublon. Le sixième demande lequel remplacer. Le Top 5 chansons ne bouge pas. Un Top 5 se vide jusqu'à zéro. Une œuvre déjà placée n'est proposée sous aucun identifiant. | top5.spec.ts |
| A08 Playlist | Rien pour l'instant : les playlists (US-29 à US-33) ne sont pas faites. Les tests sont marqués fixme. | playlist.spec.ts |
| A09 Erreurs | Sans réseau, puis quand la réponse se perd après l'enregistrement : la note, la critique, la date et la visibilité restent dans le formulaire, et Réessayer enregistre une seule écoute. La partie playlist attend US-30. | erreurs.spec.ts |
| A10 Collections | Favori et À écouter ne dépendent ni de la note ni du Top 5, et chacun se retire. Une écoute retire l'œuvre de À écouter et le dit : c'est un écart avec le dossier, décidé avec US-18. | collections.spec.ts |
| A11 Accès et sécurité | Sans compte, on lit un profil public, et Ajouter à mon journal mène à la connexion. Un signalement est confirmé. Un blocage s'annule dans les réglages. | acces.spec.ts |
| A12 Utilisation accessible | Chercher, ouvrir une fiche, noter et enregistrer au clavier seulement. Réordonner le Top 5 au clavier. axe passe sur le journal, les réglages, l'éditeur du Top 5 et la fenêtre d'écoute, en clair et en sombre. | clavier.spec.ts |
Les tests e2e habituels (tests/run.sh --deploye) complètent ceux-ci sur les écrans publics : glisser sur les étoiles, axe sans compte, états « pas accessible ».
2. À la main
Les tests ne savent pas faire ce qui suit. Compter une demi-heure.
- Connexion sociale. Se connecter avec Google sur le web. Créer un compte neuf de bout en bout (US-01), puis le supprimer avec
scripts/comptes.sh supprimer <nom> --deploye. - App mobile. Sur un iPhone et sur un Android, se connecter, ajouter une écoute notée au doigt, la retrouver dans le journal, se déconnecter.
- Lecteur d'écran. Avec VoiceOver, faire le parcours recherche, fiche, ajout au journal avec une note. Chaque bouton doit dire ce qu'il fait, et la note doit s'entendre (« 3,5 sur 5 »).
- Sans la couleur. En clair et en sombre, regarder la fiche, le journal et le Top 5 : un état (Public ou Privé, Favori, note) ne doit jamais se lire seulement à sa couleur.
- A06. Juger si un nouveau venu comprend que l'onglet Abonnements montre les personnes qu'il suit.
- Modération. Avec un compte qui a le rôle
moderation, ouvrir Modération, rejeter le signalement « Vérification avant une vague (TECH-03) » laissé parverif-a, puis traiter les vrais signalements en attente.
3. Les problèmes observés
Ce sont eux qui décident. Depuis la vague précédente, relever :
- les signalements reçus, et ce qu'ils disent du contenu publié;
- les erreurs 500 de l'API :
deploy/k8s/k3s/distant.sh themachine kubectl -n musiqud logs deploy/api --since=168h | grep '"Level":"Error"'; - les alertes de Flux dans le salon Discord (déploiements ratés);
- ce que les personnes ont écrit à l'adresse d'aide;
- les items ouverts dans Plane qui touchent un critère.
On n'élargit pas si un test ou une vérification à la main échoue sur un critère livré, ou si un problème touche la confidentialité, la perte de données ou la connexion. Un problème mineur, par exemple un contraste juste sous le seuil, ne bloque pas. Il devient un item dans Plane, avec une échéance avant la vague suivante.
Noter le résultat
Chaque vague a son item dans Plane, projet MUS, titré « Vague N : vérification ». Les problèmes relevés deviennent des items, liés à celui de la vague. L'item reprend ce tableau :
Version vérifiée : App <sha> · API <sha> (Réglages, À propos)
tests/run.sh --vague : <n> réussis, <n> échoués, <n> en attente (fixme)
| Critère | Tests | À la main | Remarques |
|---|---|---|---|
| A01 Recherche | ✅ / ❌ | ✅ / ❌ / s.o. | |
| … | | | |
| A12 Utilisation accessible | | | |
Problèmes observés depuis la vague précédente : …
Décision : élargir à … / attendre, parce que …