# 09 – Stratégie de tests, validation et qualité pour Linux BenchTools

Objectif : définir comment tester et valider chaque brique de l’application
(backend, script bench, frontend), afin d’assurer fiabilité, reproductibilité des mesures
et facilité de maintenance.

Ce document sert de guide pour écrire les tests et scénarios de validation manuelle.

---

# 1. Périmètre des tests

Les tests couvrent :

1. **Backend API**
   - Validation des endpoints
   - Validation de la persistance en base
   - Validation de la sécurité (token)
2. **Script client `bench.sh`**
   - Fonctionnement sur différentes machines Debian/Ubuntu
   - Gestion des erreurs (outils manquants, serveur indisponible)
   - Qualité du JSON envoyé
3. **Frontend WebUI**
   - Rendu des pages (Dashboard, Devices, Device Detail, Settings)
   - Consommation correcte de l’API
   - UX minimale (lisibilité, tri, navigation)
4. **Tests de bout en bout (E2E)**
   - Exécution complète d’un bench depuis un client → apparition dans le Dashboard.

---

# 2. Tests Backend

## 2.1. Types de tests

- **Tests unitaires** : fonctions isolées (scoring, mapping JSON → modèles).
- **Tests d’intégration** : endpoints FastAPI avec base SQLite de test.
- **Tests E2E API** : envoi d’un payload complet depuis un script de test.

Framework recommandé :
- `pytest`
- `httpx` ou client de test FastAPI

## 2.2. Cas de test principaux

### a) POST /api/benchmark

- [OK] Payload complet, token valide :
  - Retourne 200
  - Crée un `device` si inexistant
  - Crée un `hardware_snapshot`
  - Crée un `benchmark`
- [OK] Device existant :
  - Réutilise le `device`
- [ERR] Token manquant :
  - 401
- [ERR] Token incorrect :
  - 401
- [ERR] JSON invalide :
  - 400

### b) GET /api/devices

- [OK] Base vide → items = [].
- [OK] Avec plusieurs devices et benchmarks :
  - Retourne un `last_benchmark` cohérent.
- [OK] Paramètres `page`, `page_size` :
  - Pagination effective.

### c) GET /api/devices/{id}

- [OK] Device existant :
  - Retourne résumé, snapshot, dernier benchmark.
- [ERR] Device inexistant :
  - 404.

### d) Liens constructeur

- [OK] CRUD complet sur `/api/devices/{id}/links`.
- [ERR] URL invalide (peut être toléré ou validé selon règle).

### e) Documents

- [OK] Upload PDF :
  - Fichier stocké physiquement
  - Entrée BDD créée
- [OK] Download :
  - Renvoie bon `Content-Type`
- [ERR] doc_id invalide :
  - 404.

---

# 3. Tests Script client (bench.sh)

## 3.1. Contexte

Les tests sur `bench.sh` sont principalement :
- des tests manuels guidés
- des tests automatisables partiellement (CI dans un container Docker).

## 3.2. Cas de test

### a) Aide & usage

- `bench.sh --help` → affiche usage.
- Sans arguments → erreur claire.

### b) Prérequis

- Si `curl`, `jq`, `sysbench`, `fio` manquants :
  - message explicite
  - tentative d’installation si possible (apt-get)
  - en cas d’échec, test concerné désactivé mais script continue.

### c) Exécution minimale

- `bench.sh --server http://backend:8007/api/benchmark --token XXX` :
  - Détecte le hostname
  - Exécute les tests par défaut
  - Envoie un JSON valide (vérifiable via logs backend).

### d) Modes d’options

- `--short` :
  - Durées de tests CPU/mémoire/disk raccourcies
- `--skip-network` :
  - Aucun test iperf3, bloc `results.network` absent ou null
- `--iperf-server` avec serveur iperf opérationnel :
  - Champs réseau correctement renseignés.

### e) Gestion des erreurs réseau

- Backend down :
  - Message d’erreur clair
  - Code HTTP ≠ 200 connu
- Iperf3 indisponible :
  - Bloc network absent/null

---

# 4. Tests Frontend

## 4.1. Smoke tests (manuels)

- Accès à :
  - `/` → Dashboard
  - `/devices`
  - `/devices/{id}`
  - `/settings`
- Vérification du rendu :
  - Aucune erreur JS console
  - Chargement des datas via API
  - Tri de base dans les tableaux

## 4.2. Tests fonctionnels (scénarios)

### Scénario 1 : Premier lancement

1. Déployer l’application.
2. Vérifier Dashboard vide, message “Aucun device”.
3. Exécuter `bench.sh` sur une machine.
4. Rafraîchir Dashboard :
   - Device apparaît avec score.

### Scénario 2 : consultation d’un device

1. Cliquer sur un device dans le Dashboard.
2. Page détail :
   - Hardware résumé cohérent.
   - Dernier benchmark affiché.
3. Onglet Benchmarks :
   - Historique listé.

### Scénario 3 : Documents

1. Aller dans onglet Documents d’un device.
2. Uploader un PDF.
3. Vérifier sa présence dans la liste.
4. Télécharger pour confirmer.

### Scénario 4 : Liens constructeur

1. Onglet Links d’un device.
2. Ajouter un lien avec label + URL.
3. Vérifier qu’il est cliquable.
4. Tester suppression.

---

# 5. Tests E2E (de bout en bout)

Objectif : couvrir la chaîne complète depuis la machine cliente jusqu’au Dashboard.

### Scénario E2E type

1. Lancer backend + frontend via `docker compose up`.
2. Déployer `bench.sh` sur un client Debian.
3. Exécuter :

```bash
curl -s https://.../bench.sh | bash -s -- \
  --server http://IP_BACKEND:8007/api/benchmark \
  --token XXX \
  --iperf-server 10.0.0.10
```

4. Vérifier côté backend (logs) qu’un benchmark a été créé.
5. Ouvrir le Dashboard :
   - Device présent, scores visibles.

---

# 6. Données de test

Créer un répertoire `tests/data/` contenant :

- Exemples de payload JSON de bench :
  - `bench_full.json` (tous tests)
  - `bench_no_gpu.json`
  - `bench_short.json`
- Scripts auxiliaires :
  - `send_bench_payload.py` (envoi direct d’un payload pour tests).

---

# 7. Automatisation CI (optionnel)

Intégration avec :

- GitHub Actions
- Gitea Actions / Drone / Woodpecker

Tâches CI typiques :

1. `pytest` sur le backend
2. Lancement d’un backend en mode test
3. Envoi d’un payload JSON factice
4. Vérification de la réponse HTTP

---

# 8. Critères de qualité

L’application sera considérée comme “OK” pour usage perso si :

- Au moins 1 test unitaire par endpoint critique
- Un scénario E2E réussi
- `bench.sh` fonctionne sur :
  - 1 machine physique
  - 1 VM
- Les erreurs d’auth/token sont gérées proprement
- Le Dashboard reste utilisable avec plusieurs dizaines de devices et benchmarks

---

# 9. Améliorations possibles

- Ajout de tests de charge (Gatling / k6) sur le backend
- Ajout de tests de non-régression des scores (baseline)
- Ajout de tests visuels (Playwright, Cypress)
- Intégration d’un badge “build/test status” dans le README principal