Stratégie de Tests et Assurance Qualité

Ce document détaille la stratégie de tests mise en place pour garantir la fiabilité de l'application Project OwL. Notre approche repose sur la pyramide des tests : une base solide de tests unitaires et d'intégration, complétée par des tests de bout en bout et des validations matérielles.

A. Tests unitaires + Code Coverage

Les tests unitaires visent à valider la logique pure de notre application, indépendamment de l'interface utilisateur ou des appels réseau.

• Outils utilisés : Jest.
• Cible : Le dossier src/utils/.
• Exemple : Nous testons rigoureusement les fonctions de formatage de date (formatDateTime) et de calcul de durée (calculateDuration). Ces fonctions sont critiques car elles transforment les données brutes de l'API en informations lisibles pour l'utilisateur (ex: "Ouvert depuis 1h 30min").
• Couverture de code (Code Coverage) :
  • Nous suivons la couverture via la commande npm run test:coverage.
  • Configuration : Nous avons configuré Jest pour exclure les Server Components (Pages et Layouts) du rapport, car ils ne sont pas testables unitairement avec JSDOM. Cela nous permet d'avoir un indicateur de couverture pertinent (proche de 100%) sur la logique métier et les composants UI interactifs.

B. Tests d'intégration

Les tests d'intégration vérifient que nos composants React fonctionnent correctement ensemble et réagissent bien aux événements (clics, chargement de données).

• Outils utilisés : Jest + React Testing Library.
• Cible : Les Client Components dans le dossier components/.
• Stratégie de Mocking :
  • Nous simulons (mock) les dépendances externes comme Clerk (authentification) et notre apiClient. Cela nous permet de tester l'interface sans dépendre du backend ou de la connexion internet.
  • Nous simulons les réponses de l'API (succès, chargement, erreur) pour vérifier que l'interface réagit correctement (affichage des spinners, messages d'erreur, ou données).
• Scénarios clés testés (Focus onglet "Fenêtres") :
  1. WindowSensorCard : Vérification des changements visuels (couleur verte/orange/rouge) en fonction de l'état de la fenêtre et de la durée d'ouverture.
  2. WindowSensorsView : Vérification de l'affichage correct de la grille et du groupement par "Hub".
  3. WindowSensorDetailsModal : Test du cycle de vie complet de la modale : ouverture au clic, affichage du chargement, appel API simulé, affichage des statistiques et fermeture.

Cette structure de tests d'intégration sert de modèle et sera répliquée par les autres membres de l'équipe pour les onglets CO2, Qualité de l'air et Température.

C. Tests End-to-End (E2E)

Les tests de bout en bout simulent le parcours d'un utilisateur réel sur un navigateur complet.

• Statut : En cours de mise en place.
• Outil envisagé : Playwright (ou Cypress).
• Objectif : Valider les flux critiques de l'application qui traversent toute la stack (Frontend + API + Base de données).
• Scénario principal prévu :
  1. Un utilisateur arrive sur la page de login.
  2. Il s'authentifie (via un compte de test).
  3. Il est redirigé vers le Dashboard.
  4. Il navigue vers l'onglet "Capteurs de fenêtre".
  5. Il vérifie que les données s'affichent sans erreur réseau.

D. Tests physiques

Le projet OwL comportant une partie matérielle (IoT), des tests physiques sont indispensables pour valider la chaîne de données complète.

• Matériel testé : Boîtier ESP32, Capteurs magnétiques (Reed switch) pour les fenêtres, Capteurs CO2.
• Méthodologie :
  1. Test unitaire électronique : Vérification des tensions et du déclenchement des capteurs à l'aide de LEDs témoins et du moniteur série.
  2. Test de connectivité : Vérification de la connexion WiFi du Hub et de l'envoi des payloads JSON vers l'API.
  3. Test "Bout en Bout" physique :
     • Action : Ouvrir physiquement une fenêtre équipée.
     • Vérification : Constater la mise à jour de l'état sur le Dashboard Web (latence, exactitude de l'état).

E. Bilan

Réalisations : Nous avons mis en place une culture de test rigoureuse dès le début du développement du frontend. Actuellement, la logique utilitaire et les composants complexes de la fonctionnalité "Fenêtres" sont couverts par des tests automatisés.

Quand et Comment ? Les tests sont écrits en parallèle du développement des composants (approche proche du TDD). Ils sont exécutés automatiquement via notre pipeline d'intégration continue (GitHub Actions) à chaque Push ou Pull Request, empêchant ainsi toute régression.

Point de vue : Cette stratégie nous apporte une grande confiance dans la stabilité du code. En isolant la logique frontend via des Mocks, nous pouvons développer l'interface même si l'API ou le matériel n'est pas encore finalisé. La prochaine étape cruciale est la généralisation de ces tests aux autres onglets du dashboard par l'équipe et la finalisation des tests E2E pour sécuriser le parcours critique.