Stratégie de test - Edu-Kit
| Version : 1.2 | Date : Juin 2026 | Statut : En vigueur |
Sommaire
- Présentation
- Périmètre de test
- Approche de test (dont 3.6 Stratégie de couverture ciblée)
- Ressources
- Planification des phases de test
- Gestion des risques
- Critères de livraison
- Environnements de test
- Lexique
Métriques actuelles (Juin 2026) : plus de 1 250 tests automatisés répartis sur plus de 210 fichiers de test - OrgService (~580 tests, 107 fichiers), VmService (~670 tests, 104 fichiers dont 12 d’infrastructure), Edukit-Front (4 tests, 2 fichiers).
1. Présentation
1.1 Objet du document
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.
┌──────────────────────────────────────────────────────────────┐
│ Edukit-Front (SPA Angular) │
│ localhost:4200 │
└───────────────┬──────────────────────────┬───────────────────┘
│ REST │ REST + SignalR
┌──────────▼──────────┐ ┌──────────▼──────────────┐
│ OrgService │ │ VmService │
│ .NET 9 - :5100 │◄───│ .NET 9 - :5200 │
│ gRPC server :5101 │ │ gRPC server :5201 │
└──────────┬───────────┘ └──────────┬───────────────┘
│ │ HTTP (API REST Proxmox)
┌──────────▼───────────────────┐ ┌────▼──────────────┐
│ PostgreSQL 16 | Keycloak 26│ │ Proxmox VE 8 │
└──────────────────────────────┘ └───────────────────┘
2. Périmètre de test
2.1 Fonctionnalités couvertes
OrgService
| Domaine | Fonctionnalités testées |
|---|---|
| Utilisateurs | Création, consultation, suppression, assignation de rôle |
| Établissements | Création, mise à jour, suppression |
| Groupes | Création, archivage, gestion des membres (ajout/suppression) |
| Environnements de travail | Création, archivage, association à un template VM |
| Sessions de travail | Création, démarrage, pause, complétion, annulation |
| Licences | Émission, révocation, consultation par id, liste par établissement, recherche |
| Autorisation | Contrôle d’accès par rôle et par portée d’établissement pour chaque opération |
| Validation | Règles métier FluentValidation sur l’ensemble des commandes et requêtes |
VmService
| Domaine | Fonctionnalités testées |
|---|---|
| Templates VM | Création, activation, désactivation, archivage |
| Images OS | Gestion du catalogue |
| Packages et catégories | Gestion du catalogue, association aux templates |
| Machines virtuelles | Provisionnement Proxmox (clone, cloud-init, démarrage), cycle de vie, gestion du rollback sur échec |
| Réconciliation de statut | Synchronisation périodique Proxmox → base de données + diffusion SignalR |
| Clients gRPC | Résolution des groupes et environnements de travail vers OrgService |
| Machines virtuelles par étudiant | Création et suppression d’une VM individuelle, liste des étudiants éligibles |
| Cluster hyperviseur | Consultation et configuration des limites de ressources Proxmox |
| Statut Proxmox | Consultation de l’état des ressources de l’hyperviseur |
| Supervision des licences | Arrêt automatique des VMs dont la licence a expiré (ExpiredLicenseVmStopper) |
Edukit-Front
| Domaine | Fonctionnalités testées |
|---|---|
| Composant racine | Initialisation de l’application (AppComponent) |
| Gestion des utilisateurs | Initialisation du composant liste |
2.2 Fonctionnalités hors périmètre (intentionnellement)
| Élément exclu | Justification |
|---|---|
Middleware GlobalExceptionHandlerMiddleware |
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.
3.2 Pyramide de tests
┌──────────┐
│ E2E │ Non implémenté - futur
┌──┴──────────┴──┐
│ Infrastructure │ VmService uniquement (12 fichiers)
┌──┴─────────────────┴──┐
│ Tests unitaires │ Couche principale - plus de 200 fichiers
└────────────────────────┘
> 1 250 tests automatisés au total
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 |
3.6 Stratégie de couverture ciblée
Le projet adopte une stratégie de test orientée impact : seules les parties du code réellement modifiées ou nouvellement introduites font l’objet de nouveaux tests. Une fonctionnalité déjà couverte par ses tests existants, et dont le code n’a pas changé, n’est pas re-testée systématiquement lors d’ajouts adjacents.
Ce principe repose sur la confiance accordée aux tests déjà en place : si une suite de tests valide une fonctionnalité A et que le développement d’une fonctionnalité B n’en modifie pas l’implémentation, les tests de A constituent une garantie de non-régression suffisante - les réécrire serait du travail redondant sans valeur ajoutée.
Exemple concret - Démarrage des séances de travail
Le démarrage manuel d’une séance (StartSessionManually) était couvert par sa propre suite de tests (handler, validator, autorisation). Lors de l’ajout du démarrage automatique (StartSessionAutomatically), seule la logique de démarrage automatique a été testée. Le chemin de démarrage commun (vérification de l’état de la séance, transition vers InProgress, persistance) n’a pas été re-testé : son code n’avait pas changé et ses tests existants continuaient à passer.
Avant l'ajout Après l'ajout
───────────────────── ─────────────────────────────────────
StartManually ✓ (testé) StartManually ✓ (tests inchangés - non re-testés)
StartAutomatically ✓ (nouveaux tests écrits)
Logique commune → couverte implicitement par les deux
Limites et garde-fous
Cette approche nécessite que le code partagé entre les deux fonctionnalités soit clairement identifié. Si une refactorisation touche un chemin commun, les tests des deux fonctionnalités impactées doivent être revus. La revue de PR est le moment clé pour repérer ces cas.
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. Plus de 500 règles C# actives dont plus de 50 sécurité, plus de 90 fiabilité et plus de 300 maintenabilité. | 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 ProxmoxVmLifecycleService- start/stop/destroy des VMsVmStatusReconciler- réconciliation périodique des statutsExpiredLicenseVmStopper- arrêt automatique des VMs sur licence expirée- Clients gRPC (
GrpcGroupResolutionService,GrpcWorkEnvironmentResolutionService)
5.3 Phase 3 - Validation manuelle (avant ouverture de la PR)
Le développeur valide manuellement sur l’environnement local :
- Les endpoints modifiés via Swagger UI (
http://localhost:5100/swaggerou:5200/swagger) - Les parcours frontend correspondants sur
http://localhost:4200
Les résultats de cette validation sont documentés dans la section “Testing Notes” de la description de la PR.
5.4 Phase 4 - Validation CI (lors de chaque PR)
Azure DevOps exécute automatiquement :
- Build de la solution
- Exécution des tests (
dotnet test/npx ng test) - Collecte de la couverture (coverlet)
- Analyse SonarQube - quality gate bloquant
SonarQube Cloud publie directement des commentaires sur la PR pour chaque règle non respectée (sécurité, fiabilité, maintenabilité). Ces commentaires sont traités comme faisant partie intégrante de la revue de code : le reviewer et l’auteur de la PR en prennent connaissance et les violations sont corrigées avant le merge, au même titre qu’un retour humain.
5.5 Évolutions futures
| Phase | Description | Horizon |
|---|---|---|
| Tests d’infrastructure OrgService | Ajouter un projet InfrastructureTests pour les clients gRPC (symétrie avec VmService) |
Court terme |
| Tests composants Angular | Étendre la couverture Vitest aux guards, services et composants de fonctionnalité | Court terme |
| Tests E2E | Playwright ou Cypress - parcours critiques (connexion Keycloak, provisionnement VM, cycle d’une session de travail) | Moyen terme |
6. Gestion des risques
| ID | Risque | Probabilité | Impact | Criticité | Mitigation |
|---|---|---|---|---|---|
| R1 | Couverture frontend < 5 % - bugs UI non détectés automatiquement | Élevée | Moyen | Élevée | 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) |