Ce document définit la stratégie de test appliquée au projet Edu-Kit, une plateforme de virtualisation pédagogique permettant aux établissements d’enseignement de mettre à disposition des machines virtuelles pour leurs étudiants.
Il précise les objectifs qualité, les techniques et niveaux de test retenus, les ressources mobilisées, le planning des phases de test et les critères d’acceptation à la livraison.
1.2 Contexte projet
Edu-Kit est une application à architecture microservices composée de trois dépôts :
Composant
Technologie
Rôle
OrgService
.NET 9 / C# — Clean Architecture + CQRS
Gestion des organisations, utilisateurs, groupes, environnements de travail et sessions
VmService
.NET 9 / C# — Clean Architecture + CQRS
Gestion des templates VM, provisionnement Proxmox et état temps réel des machines virtuelles
Edukit-Front
Angular 21 / TypeScript
Interface utilisateur (SPA) consommant les deux services via REST et SignalR
L’authentification est déléguée à Keycloak (protocole OIDC/PKCE) avec quatre rôles applicatifs : superadmin, admin, teacher, student.
Logique de mapping simple ; comportement couvert implicitement par les tests des handlers
Migrations EF Core
Vérifiées au démarrage automatique en environnement de développement
Keycloak (realm, émission de tokens JWT)
Infrastructure externe — validée sur les environnements de dev/staging
SftpSnippetUploader
Requiert une vraie session SSH ; difficilement simulable de façon fiable en test unitaire
Endpoints Minimal API
Logique propre quasi nulle ; couverts par les tests des handlers et les tests manuels Swagger
Tests end-to-end (E2E)
Non implémentés dans l’état actuel du projet (voir section 5)
3. Approche de test
3.1 Méthodologie
Le projet adopte une approche Agile à intégration continue. À la différence du modèle en V qui sépare les phases de développement et de test en cascade, les tests sont écrits en parallèle du code de production, feature par feature, à l’intérieur de chaque sprint.
Modèle en V (non retenu) Approche Agile (Edu-Kit)
──────────────────────── ────────────────────────
Conception Sprint n
↓ ┌────────────────────────────────────────┐
Développement │ Dev → TU écrits → PR → CI → Merge │
↓ │ ↑ │
Tests unitaires │ Tests d'infra si composant modifié │
↓ └────────────────────────────────────────┘
Tests d'intégration Sprint n+1
↓ ┌────────────────────────────────────────┐
Tests système │ Dev → TU écrits → PR → CI → Merge │
↓ └────────────────────────────────────────┘
Tests d'acceptation
Principes clés :
Chaque développeur est responsable des tests de ses fonctionnalités.
Un quality gate bloquant (SonarQube, couverture ≥ 60 %) empêche le merge si les seuils ne sont pas atteints.
Les tests sont exécutés automatiquement dans le pipeline Azure DevOps à chaque push et à l’ouverture d’une pull request.
La base de la pyramide représente la majorité des tests : rapides, déterministes, sans dépendances externes. Les tests d’infrastructure couvrent les adaptateurs vers les systèmes tiers. Le niveau E2E est prévu comme évolution future.
3.3 Types de tests
Type
Description
Repos
Test unitaire
Vérifie une unité de code isolée (entité, validator, handler). Toutes les dépendances externes sont mockées via Moq.
OrgService, VmService, Edukit-Front
Test d’infrastructure
Vérifie les adaptateurs vers des systèmes externes (Proxmox HTTP, gRPC) avec des dépendances d’infrastructure simulées.
VmService
Test manuel
Validation fonctionnelle via Swagger UI (/swagger) ou l’interface Angular, sur l’environnement de développement local.
Tous les composants
3.4 Niveaux de tests
Niveau
Description
Statut
Unitaire
Test d’une classe ou méthode isolée, sans dépendance réelle
Implémenté — xUnit / Vitest
Composant
Test d’un composant Angular seul, avec Angular TestBed
Partiellement — 2 fichiers spec
Intégration partielle
Test d’un service avec ses adaptateurs d’infrastructure mockés
Implémenté — VmService InfrastructureTests
Système (E2E)
Test du parcours utilisateur complet, à travers toutes les couches
Non implémenté
Acceptation
Validation fonctionnelle par l’équipe, sur environnement de dev
Manuel uniquement
3.5 Techniques de test
Technique
Définition
Application dans Edu-Kit
Boîte blanche
Le testeur connaît l’implémentation interne et structure ses cas de test en conséquence
Tests unitaires et d’infrastructure : mocking ciblé, couverture des branches métier
Boîte noire
Le testeur se base uniquement sur les entrées/sorties, sans connaître le code
Tests manuels Swagger et interface Angular
4. Ressources
4.1 Outils
Outil
Version
Rôle
Repos
xUnit
2.9.2
Framework de test .NET
OrgService, VmService
Moq
4.20.72
Mocking des dépendances
OrgService, VmService
FluentAssertions
6.x
Assertions lisibles en chaîne
OrgService, VmService
coverlet.collector
6.0.2
Collecte de couverture de code
OrgService, VmService
Vitest
4.0.8
Framework de test JavaScript/TypeScript
Edukit-Front
jsdom
27.1.0
Émulation du DOM navigateur en Node.js
Edukit-Front
Angular TestBed
21.x
Instanciation de composants Angular
Edukit-Front
SonarQubeCloud
—
Analyse statique, suivi couverture, quality gate
Tous
Azure DevOps
—
Pipeline CI/CD — exécution automatique des tests
Tous
Docker
—
Orchestration de PostgreSQL 16 et Keycloak 26 en dev
Tous
4.2 Équipe
Il n’existe pas de rôle QA dédié dans l’équipe. La qualité est une responsabilité collective et intégrée au développement.
Responsabilité
Acteur
Rédaction des tests unitaires et d’infrastructure
Développeur auteur de la fonctionnalité
Revue de la qualité des tests
Reviewer de la pull request
Suivi de la couverture et des quality gates
Pipeline CI — SonarQube automatique
4.3 Environnements
Voir la section 8 pour le détail des environnements et leurs configurations.
5. Planification des phases de test
5.1 Phase 1 — Tests unitaires (pendant chaque sprint)
Toute nouvelle commande ou requête CQRS doit être accompagnée de trois fichiers de test, conformément au Definition of Done :
UnitTests/
Validators/
[Nom]CommandValidatorTests.cs ← un test par règle de validation
Authorization/
[Nom]AuthorizationHandlerTests.cs ← SA bypass, caller absent, scope invalide, happy path
Handlers/[Feature]/
[Nom]CommandHandlerTests.cs ← ressource absente, violations métier, chemin nominal
Les tests sont écrits en parallèle du code de production et exécutés localement avant toute PR.
5.2 Phase 2 — Tests d’infrastructure (lors de modifications des adaptateurs)
Les tests du projet InfrastructureTests (VmService) sont mis à jour ou étendus dès qu’une des classes suivantes est modifiée :
VmProvisioningService — orchestrateur de provisionnement Proxmox
VmLifecycleService — start/stop des VMs
VmStatusPollingService — réconciliation périodique des statuts
Prioriser l’ajout de tests sur les guards et les pages principales
R2
Absence de tests E2E — régressions cross-services non détectées
Certaine
Élevé
Élevée
Tests manuels avant chaque release ; planification E2E (§ 5.5)
R3
Keycloak non testé — pannes d’authentification silencieuses
Faible
Élevé
Moyenne
Validation manuelle avec le compte testadmin en dev ; monitoring en staging
R4
SftpSnippetUploader exclu des tests — erreur SFTP non détectée avant déploiement
Faible
Moyen
Faible
Validation sur l’environnement Proxmox de dev ; gestion d’erreur explicite dans le code
R5
Asymétrie entre OrgService (pas d’InfrastructureTests) et VmService
Certaine
Faible
Faible
Ajout planifié (§ 5.5)
7. Critères de livraison
7.1 Grille de criticité des anomalies
Niveau
Définition
Exemple
Bloquant
Fonctionnalité centrale inopérante — livraison impossible
Provisionnement VM impossible, authentification cassée
Critique
Impact fonctionnel majeur sans contournement disponible
Rôle incorrect accordé à un utilisateur, données corrompues
Majeur
Impact fonctionnel significatif avec contournement possible
Pagination incorrecte, filtre de recherche non appliqué
Mineur
Impact limité — cosmétique ou inconfort utilisateur
Libellé incorrect, comportement UX inattendu non bloquant
7.2 Seuils d’acceptabilité
Critère
Seuil acceptable
Bloquant si
Tests unitaires en succès
100 %
< 100 %
Couverture de code — backend
≥ 60 %
< 60 %
Couverture de code — frontend
≥ 40 % (objectif)
Non bloquant actuellement
SonarQube Quality Gate
Grade A
Grade B ou inférieur
Anomalies bloquantes ouvertes
0
≥ 1
Anomalies critiques ouvertes
0
≥ 1
Anomalies majeures ouvertes
≤ 2
> 2
Anomalies mineures ouvertes
Non bloquant
—
7.3 Conditions supplémentaires
Tous les checks du pipeline CI sont au vert (build, lint, tests, SonarQube).
La PR a reçu au moins une approbation de reviewer.
La validation manuelle des parcours principaux est documentée dans la PR (section “Testing Notes”).
8. Environnements de test
8.1 Environnement local (développement)
Composant
URL
Version
OrgService API
http://localhost:5100
.NET 9.0
OrgService gRPC
http://localhost:5101
.NET 9.0
VmService API
http://localhost:5200
.NET 9.0
VmService gRPC
http://localhost:5201
.NET 9.0
Edukit-Front
http://localhost:4200
Angular 21.1
Keycloak
http://localhost:8080
26.x
PostgreSQL
localhost:5432
16
Proxmox VE
Accès restreint — secrets via dotnet user-secrets
8.x
Les dépendances (PostgreSQL + Keycloak) sont démarrées via Docker Compose. La base de données est migrée et seedée automatiquement au démarrage des services.
Les tests unitaires et d’infrastructure s’exécutent entièrement en mémoire — aucune dépendance Docker n’est requise pour les lancer.
8.2 Environnement CI/CD (Azure DevOps)
Composant
Détail
Pipeline
azure-pipelines.yml — déclenché à chaque push et à l’ouverture d’une PR
Exécution des tests backend
dotnet test — sans Docker, en mémoire
Exécution des tests frontend
npx ng test — Vitest + jsdom
Collecte de couverture
Rapport coverlet envoyé à SonarQubeCloud
Quality Gate
Grade A requis — bloquant avant merge vers dev ou main
9. Lexique
Terme
Définition
CQRS
Command Query Responsibility Segregation — pattern séparant les opérations d’écriture (Commands) des opérations de lecture (Queries)
Clean Architecture
Architecture logicielle organisant le code en couches concentriques (Domain → Application → Infrastructure → API) avec des dépendances orientées vers l’intérieur
MediatR
Bibliothèque .NET implémentant le pattern Mediator ; les handlers sont découplés de leurs appelants via des messages typés
Mock
Objet simulé remplaçant une dépendance réelle lors d’un test, permettant de contrôler son comportement et de vérifier les interactions
FluentValidation
Bibliothèque .NET de validation de modèles basée sur des règles chaînées et expressives
FluentAssertions
Bibliothèque .NET proposant une syntaxe d’assertions lisible (result.Should().Be(...))
xUnit
Framework de test unitaire pour .NET, utilisé en remplacement de NUnit/MSTest
Vitest
Framework de test JavaScript/TypeScript léger, compatible avec l’écosystème Vite/Angular
jsdom
Implémentation JavaScript du DOM du navigateur pour Node.js, permettant de tester des composants sans navigateur réel
Boîte blanche
Technique de test où le testeur a connaissance de l’implémentation interne
Boîte noire
Technique de test où le testeur se base uniquement sur les entrées/sorties sans connaître le code
Quality Gate
Ensemble de critères de qualité configurés dans SonarQube dont le non-respect bloque le merge
CI/CD
Continuous Integration / Continuous Delivery — automatisation du build, des tests et du déploiement
gRPC
Protocole d’appel de procédure à distance haute performance basé sur HTTP/2 et Protocol Buffers
OIDC / PKCE
OpenID Connect / Proof Key for Code Exchange — flux d’authentification sécurisé utilisé par Keycloak
Proxmox VE
Hyperviseur open-source de virtualisation (VMs KVM)
SignalR
Bibliothèque ASP.NET Core permettant des communications temps réel entre serveur et clients (WebSocket)
E2E
End-to-End — test du parcours complet d’un utilisateur à travers toutes les couches du système
SPA
Single Page Application — application web dont le rendu est géré côté client (Angular dans ce projet)