Tests

Vérifiez votre changement sur votre machine avant de l’envoyer.

Avant de commencer

• Terminez la Configuration. Les tests Go servent l’application web compilée, donc compilez-la d’abord.

• Installez une fois le navigateur de test :

  npx --prefix app/frontend playwright install chromium

Lancer les contrôles de tous les jours

1. Compilez le code Go et passez-le à vet :

   go build ./...
   go vet ./...

2. Lancez les tests Go :

   go test ./...

3. Vérifiez et testez l’application web :

   npm --prefix app/frontend run check
   npm --prefix app/frontend run lint
   npm --prefix app/frontend run test

4. Lancez les règles sur les couches et l’organisation des fichiers :

   go test -tags structure ./app/backend/tools/structurecheck

Vous ne devriez voir aucun échec. La CI lance les mêmes commandes, celles de Go sur amd64 et arm64, plus une exécution avec le détecteur d’accès concurrents (go test -race ./...).

Note

Le go test ./... complet dure longtemps. Utilisez make test, qui fixe un délai maximal de 25 min. Celui de Go par défaut est de 10 min.

Lancer les tests de bout en bout

Les tests de bout en bout pilotent un vrai navigateur face à un vrai programme. Lancez le projet de la zone que vous avez touchée :

npm --prefix app/frontend run e2e -- --project=movies

L’exécution démarre son propre HolyArrs sur un dossier de configuration neuf. Le projet setup crée d’abord le propriétaire, et la plupart des autres projets l’attendent. Lancez la suite complète sans --project avant une publication.

Options

Quels projets lancer

Vous avez modifié	Lancez
Les films	movies
Les séries	shows
Les demandes	requests, lists, reports
Les téléchargements	sources, downloaders, downloads
La connexion et les utilisateurs	accounts, kid
La santé et les planifications	schedules, controls
La mise en page	desktop, phone, a11y

Les projets sont nommés dans app/frontend/playwright.config.ts. Un projet qui dépend d’un autre le lance d’abord.

Où va un nouveau test

Type	Où
Go	À côté du fichier qu’il teste
Unitaire web	À côté de son fichier, sous le nom name.test.ts
De bout en bout	app/tests/<module>/

N’appelez jamais un vrai service extérieur. Ajoutez un substitut sous app/tests/fakes. Un test qui passe seulement sur votre machine est cassé.

Si ça ne fonctionne pas

Symptôme. Un contrôle de structure échoue. Cause. Le message indique le fichier et la règle que vous avez enfreinte. Solution. Déplacez le code, ou passez des données simples depuis le module supérieur. Voir Modules.

Symptôme. Les tests de bout en bout ne démarrent pas. Cause. Le navigateur de test n’est pas installé. Solution. Lancez la ligne playwright install ci-dessus.

Symptôme. Les tests Go échouent à cause de pages manquantes. Cause. L’application web n’est pas compilée. Solution. Lancez npm --prefix app/frontend run build.

Pour les experts

Tags de build

Un test avec un tag est ignoré par un simple go test ./.... Passez -tags <tag> pour le lancer.

Tag	Contient
structure	Les règles sur les couches, l’organisation des fichiers, l’emplacement du SQL et les commentaires dans tools/structurecheck
measure	Les contrôles de durée des téléchargements
lab	Des tests face à de vraies applications dans un labo de test. Ils lisent HOLYARRS_LAB_* et sont ignorés quand ces variables ne sont pas définies
labms, livesubs	Les tests en labo pour les serveurs multimédias et les sites de sous-titres réels

Tests longs et tests de panne

La CI les lance en plus des tests simples. Lancez-les avant une publication.

go test -count=1 -run '^TestFault|^TestCrashInEveryLoopIsContained$' ./app/backend/cmd/holyarrs
HOLYARRS_RESTART_TIMING=1 go test -count=1 -run '^TestCrashRestartTime$' ./app/backend/cmd/holyarrs
HOLYARRS_MEMORY=1 go test -count=1 -timeout 30m -run '^TestMemoryPartsRuns$' ./app/backend/cmd/holyarrs
go test -count=1 -run '^TestDownloaderConformance$' ./app/backend/internal/downloads

Variable	Ce que ça fait
HOLYARRS_FAULT_OUT	Le fichier où les tests de panne écrivent leur tableau
HOLYARRS_RESTART_TIMING, HOLYARRS_RESTART_TIMING_OUT	Activent la mesure du temps entre le plantage et la connexion, et nomment son fichier de sortie
HOLYARRS_MEMORY, HOLYARRS_MEMORY_OUT	Activent les tests de mémoire et nomment leur fichier de sortie
HOLYARRS_CRASH_RUNS, HOLYARRS_CRASH_SEED	Le nombre de tours et la graine de la boucle de plantages dans app/backend/internal/mediafiles/dbtests (crash_test.go), qui est ignorée avec -short

Serveurs de substitution et variables

Les tests de bout en bout démarrent des serveurs de substitution pour les clients de téléchargement, les sources et le serveur de métadonnées, donc aucun test n’atteint un vrai service. Les tests définissent des variables comme HOLYARRS_TMDB_URL, HOLYARRS_MUSICBRAINZ_URL, HOLYARRS_PLEX_URL et HOLYARRS_QBITTORRENT_URL pour diriger le programme vers eux. Une vraie installation n’en a jamais besoin.

Le contrat de l’API a ses propres tests. TestOpenAPIGenerated échoue quand openapi.json s’écarte des routes, et l’instantané de la table des routes dans tools/structurecheck/testdata échoue à la moindre route ajoutée, supprimée ou déplacée.

Voir aussi

• Contribuer
• Modules
• Publier une version