-
Notifications
You must be signed in to change notification settings - Fork 0
09. Testing
Heureusement pour nous, Django intègre par défaut la librairie Python unittest. Nous pouvons donc facilement exécuter des tests unitaires et d'intégration sur la backend avec la commande manage.py test.
Des tests unitaires ont été réalisés sur mon User Story, l'attribution de permissions aux utilisateurs. Des cas valides ont été vérifiés, ainsi que le rejet d'une multitude de cas invalides (mauvais format, mauvaises données), afin de valider la robustesse du code. Voici le résultat obtenu :
$ docker exec -it integration-backend python manage.py test permissions
Found 16 test(s).
Creating test database for alias 'default'...
System check identified no issues (0 silenced).
................
----------------------------------------------------------------------
Ran 16 tests in 5.447s
OK
Destroying test database for alias 'default'...
Des tests ont été réalisés pour mon US perso, la création, la suppression et la modification de groupe ont été testé. De plus, l'ajout et la suppression d'utilisateurs à l'intérieur de ce groupe ont aussi été testé à l'aide de la librairie Django. Voici les résultats :
docker exec -it integration-backend python manage.py test users
Found 6 test(s).
Creating test database for alias 'default'...
System check identified no issues (0 silenced).
✅ AC1: Group creation passed
.✅ AC2: Adding members passed
.✅ AC3: Group deletion passed
.✅ User CRUD: Creation passed
.✅ User CRUD: Deletion passed
.✅ User CRUD: Update passed
.
----------------------------------------------------------------------
Ran 6 tests in 4.049s
OK
Destroying test database for alias 'default'...
Nous avons également rédigé des tests d'intégration sur la logique métier, en suivant des scénarios spécifiques représentant des actions qui seront courantes dans la durée de vie de l'application :
- Onboarding d'un nouvel utilisateur : création d'utilisateur, assignation à des groupes, setup de code de keypad et de badge, setup de permissions.
- Création d'un bâtiment : ajout de serrures, assignation à des groupes setup de permissions, réservabilité.
- Authentification physique d'un utilisateur avec octroi des permissions correspondantes.
$ docker exec -it integration-backend python manage.py test tests.integration_tests
Found 3 test(s).
Creating test database for alias 'default'...
System check identified no issues (0 silenced).
...
----------------------------------------------------------------------
Ran 3 tests in 2.034s
OK
Destroying test database for alias 'default'...
Nous avons finalement écrit quelques tests end-to-end pour vérifier que l'utilisateur final puisse réellement effectuer les actions décrites dans le code. Les tests rédigés portent sur un scénario classique d'inscription d'un utilisateur et de créations de locks. Pour cela, nous avons créé un nouveau conteneur Playwright, qui se lance uniquement lorsque le Docker Compose est lancé avec l'argument --profile testing. Lorsque cela est fait, nous pouvons exécuter manuellement les tests E2E et observer le résultat. Notons que le conteneur tourne en headless pour de meilleures performances.
$ docker exec -it integration-e2e npx playwright test
Running 6 tests using 1 worker
······
6 passed (8.5s)
Une fois notre maquette de porte réalisée, nous avons testé le bon envoi des requêtes API et de la réception par le serveur. Nous avons réalisé ces tests d'acceptance manuellement, car les endpoints sont testés individuellement, et qu'il est assez simple de vérifier si l'ouverture de la porte fonctionne ou non. Nous aurions pu réaliser des tests dans des environnements virtualisés, mais en restant honnêtes et réalistes, cela n'aurait pas apporté énormément au projet.
E. Bilan (Qu'avez-vous réalisé comme tests ? Quand ? Comment ? De Quel type ? Quel est votre point de vue ? )
Après la réalisation d'une multitude de tests unitaires, d'intégration, end-to-end, et physiques (manuels), nous avons assuré que les fonctionnalités de notre projet sont correctement implémentées et robustes.
Nous n'avons pas opté pour un Test-Driven-Development, qui aurait pu amener notre projet à cocher davantage de critères de fiabilité. Cependant, étant donné que nous sommes poussés à réaliser individuellement nos User Stories du début à la fin plutôt qu'en tant qu'équipe de développement, nous devons écrire nous-même les tests des US que nous implémentons, contrairement aux équipes de tests que l'on peut retrouver dans l'industrie. Nous avons donc opté pour un cycle de développement standard où les tests sont écrits après l'impléméntation.
US Perso Simon : Schéma interactif
Pour la partie Backend, nous avons utilisé le framework de test natif de Django (unittest). Les tests se concentrent sur l'application Schematics, qui gère la logique des bâtiments, des plans (schémas) et du positionnement des serrures.
Les tests couvrent les fonctionnalités critiques suivantes :
- Structure des données : Validation du format JSON renvoyé au frontend pour l'éditeur graphique.
- Cycle de vie : Sauvegarde complète (Création de murs/serrures -> Modification -> Vérification en base de données).
- Résilience : Gestion des erreurs, notamment la vérification que le serveur ne plante pas si un ID de serrure invalide est envoyé (voir le warning dans les logs ci-dessous).
- CRUD : Gestion des bâtiments.
Résultat de l'exécution :
$ docker exec -it integration-backend python manage.py test schematics
Found 8 test(s).
Creating test database for alias 'default'...
System check identified no issues (0 silenced).
.......Warning: Lock with id 999999 not found. Skipping.
.
Ran 8 tests in 0.078s
OK
Destroying test database for alias 'default'...Pour le frontend, nous utilisons Jest et React Testing Library. L'enjeu principal était de tester le composant KonvaCanva, qui utilise la librairie graphique konva (Canvas HTML5) pour afficher le plan interactif.
Cette librairie posait un problème de compatibilité majeur dans l'environnement de test (erreur ESM vs CommonJS). Nous avons résolu cela via une stratégie de Mocking Global (détaillée en section D).
Les tests vérifient :
- App.test.tsx : Le montage correct de l'application et la redirection vers le Login si l'utilisateur n'est pas authentifié.
- KonvaCanva.test.tsx : Le chargement des données depuis l'API, le rendu des mocks graphiques, et l'envoi correct des données lors de la sauvegarde.
Résultat de l'exécution :
$ docker exec -it integration-frontend npm test
PASS src/components/KonvaCanva.test.tsx
PASS src/App.test.tsx
Test Suites: 2 passed, 2 total
Tests: 3 passed, 3 total
Snapshots: 0 total
Time: 3.973 s, estimated 6 s
Ran all test suites.Nous avions prévu d'exécuter des tests End-to-End via Playwright (conteneur integration-e2e) pour valider le parcours complet utilisateur de manière automatisée.
Cependant, nous avons rencontré des problèmes de connectivité persistants entre le conteneur de test et le réseau Docker interne (problèmes de résolution DNS entre le runner Playwright et le frontend). Malgré deux heures d'investigation et de tentatives de configuration, nous n'avons pas réussi à stabiliser l'environnement E2E pour cette livraison.
En conséquence, la validation du flux complet a été effectuée via des tests manuels rigoureux. Nous avons vérifié manuellement que l'interface graphique communique correctement avec le backend pour placer, déplacer et sauvegarder les serrures sur les plans.
Pour rendre les tests unitaires frontend fonctionnels malgré l'utilisation d'une librairie graphique complexe, nous avons dû modifier le fichier de configuration frontend/src/setupTests.ts.
L'environnement de test standard (JSDOM) ne possède pas de "vrai" Canvas HTML5. Nous avons donc implémenté des "Mocks" (simulations) :
-
Mock de react-konva : Les composants graphiques (Stage, Layer, Rect) sont transformés en simples balises
<div>HTML lors des tests. Cela permet à React Testing Library de vérifier leur présence dans le DOM sans erreur de rendu. - Mock de konva : Contournement de l'import ESM pour éviter les erreurs de syntaxe Javascript que l'outil de test ne gère pas nativement.
Le bilan de cette phase de test est positif sur les composants critiques, malgré les difficultés sur l'automatisation complète :
Fiabilité Backend & Frontend : Les tests unitaires et d'intégration sont au vert. Nous avons garanti la robustesse de l'API schematics et la capacité du frontend à traiter les données sans erreur. La solution de mocking mise en place pour le Canvas assure la maintenabilité future du code.
Dette technique E2E : L'échec de la mise en place de l'automatisation E2E est un point d'attention identifié. Bien que pallié par des tests manuels pour cette itération, la résolution des problèmes de réseau Docker sera nécessaire pour assurer une non-régression automatique à l'avenir.
video : US-perso-simon_Tests.mp4.zip