Tests automatisés

Votre objectif

Tester votre application afin d'en assurer la qualité et le bon fonctionnement.

Détails de la tâche

Valant pour 20% de la note finale, vous aurez à créer des tests pour votre application.

Vous aurez aussi à remettre un plan de test à la semaine 3, valant pour 5% de la note finale.

Vous devez développer des tests pour tester le bon fonctionnement de votre application, ainsi que des tests pour vérifier les correctifs apportés suite à la revue de code de l'autre équipe.

attention

Bien que vous deviez créer autant des tests unitaires que d'intégration, il est de votre responsabilité de choisir le bon type de test en fonction de ce que vous avez à tester:

• Test unitaire
• Test d'intégration
• Test d'intégration E2E (ex.: Playwright)

Il est aussi de votre responsabilité de choisir combien de tests unitaires vs. intégration.

Type de test	Nombre de tests / coéquipier	Tests totaux pour une équipe de 3	Tests totaux pour une équipe de 4
Tests de fonctionnalités, composants ou fonctions	8	24	32
Tests des correctifs en lien avec la revue de code	2	6	8
TOTAL	10	30	40

Création d'un plan de tests

Avant de vous lancer à l'aveuglette dans la création de tests, prenez le temps d'évaluer ce que vous testerez (fonctions, fonctionnalités, cas de figures/d'utilisation, quels aspects du backend, quels aspects du frontend, etc.) et de vous répartir le travail.

Consignez le tout dans un fichier partagé (Confluence, Google Sheets, Airtable, Excel, etc.). De plus, maintenez-le à jour lorsqu'un test est complété ou que vous apportez une modification à ce que vous testez.

Cela constituera votre plan de tests: il résumera les fonctionnalités à tester, les différents scénarios, les types de test et ce dernier sera utilisé lors de la correction.

La première version de votre plan de test sera à remettre à la semaine 3 et devra comprendre, pour chaque fonctionnalité à tester:

• Fonction ou fonctionnalité à tester
• Scénario(s) de test
• Priorité du scénario
• Type de test du scénario: unitaire ou intégration
• Identification de s'il s'agit du frontend ou du backend
• Responsable (coéquipier) du test
• Statut (pour vous aider à suivre votre progression)

Voici un exemple de plan de tests. Vous pouvez aussi voir plus d'informations sur les tests dans la page dédiée à ce sujet: Tests et plan de tests.

important

Un test, bien qu'au singulier, teste habituellement plusieurs scénarios. Par exemple, pour un test d'intégration permettant l'inscription d'un utilisateur:

• Le test vérifiera évidemment qu'il est possible d'inscrire un utilisateur avec les données attendues (courriel, mot de passe, etc.)
• Le test pourrait ensuite vérifier qu'inscrire un utilisateur avec un courriel déjà pris empêche l'inscription et génère une erreur
• Il pourrait aussi tester qu'une tentative d'inscription avec des données inadéquates (manque un champ, longueur maximale ou minimale d'un champ non respectée, etc.) ne permet pas l'inscription et que les validations échouent.

Votre plan de tests aura plus de lignes que le nombre de tests demandés! Pour 1 test de fonctionnalité (ex.: connexion), vous aurez quelques scénarios

Fonctionnalité	Scénario de test	Type	Frontend/Backend	Priorité	Responsable	Statut
Authentification
Connexion	Identifiants valides → redirection dashboard	Intégration	Backend	Haute	Claire Cliche	Complété
Connexion	Mot de passe invalide → message d'erreur	Intégration	Backend	Haute	Claire Cliche	Complété
Connexion	Compte inexistant → message d'erreur	Intégration	Backend	Haute	Bobby Bonzini	En cours
Connexion	Tentatives multiples → verrouillage compte	Intégration	Backend	Haute	Bobby Bonzini	À faire
Inscription	Données valides → création compte	Intégration	Backend	Haute	Claire Cliche	Complété
Inscription	Email déjà utilisé → erreur	Intégration	Backend	Haute	Bobby Bonzini	Complété
Inscription	Mot de passe trop faible → erreur	Intégration	Backend	Moyenne	Bobby Bonzini	Complété
Catalogue
Recherche	Terme existant → affiche résultats	Intégration	Backend	Moyenne	Lucien Lupien	Complété
Recherche	Aucun résultat → message approprié	Intégration	Backend	Basse	Claire Cliche	À faire
Filtres	Filtre par prix → résultats corrects	Intégration	Backend	Moyenne	Lucien Lupien	En cours
Panier
Ajout produit	Produit valide → ajouté au panier	Intégration	Backend	Haute	Bobby Bonzini	Complété
Ajout produit	Quantité > stock → erreur	Intégration	Backend	Haute	Bobby Bonzini	Complété
Modification quantité	Quantité valide → total recalculé	Intégration	Backend	Haute	Lucien Lupien	Complété
Modification quantité	Quantité = 0 → produit retiré	Intégration	Backend	Moyenne	Lucien Lupien	À faire
Commande
Passage commande	Parcours complet → commande créée	E2E	Frontend	Haute	Claire Cliche	En cours
Calcul total	Prix, taxes, rabais → total correct	Unitaire	Backend	Haute	Bobby Bonzini	Complété
Validation adresse	Adresse incomplète → erreur	Unitaire	Backend	Moyenne	Lucien Lupien	À faire
Validations
Formatage prix	Affiche le prix en devise locale	Unitaire	Frontend	Basse	Lucien Lupien	Complété
Validation courriel	Format invalide → retourne erreur	Unitaire	Frontend	Moyenne	Bobby Bonzini	Complété
Validation téléphone	Format invalide → retourne erreur	Unitaire	Frontend	Moyenne	Bobby Bonzini	À faire
Parcours utilisateur
Achat complet	Recherche → panier → paiement → confirmation	E2E	Frontend	Haute	Claire Cliche	À faire

Tests des correctifs en lien avec la revue de code

De la semaine 2 à 4, une revue de code sera faite par une autre équipe.

• Pour chaque bug trouvé dans le code, vous devez corriger le code.
• Vous devez effectuer le ou les tests nécessaires pour vérifier que le bug est corrigé.
• Vous devez faire minimum 2 tests par coéquipier (pour des bugs différents évidemment).
• Le test doit démontrer que le problème est corrigé et que la fonctionnalité a le comportement attendu.
• Vous devez indiquer le # de l’issue dans le code du test.
• Le merge request doit faire référence à l'issue et le code du test doit indiquer le # de l’issue.

Les tests de correctifs ne comptent pas comme tests unitaires ou tests d'intégration.

Précisions sur les tests

Vous serez évalués sur la qualité, la couverture, la pertinence et le respect de la quantité requise de tests.

Les tests doivent être...

• pertinents et vérifier quelque chose (bien essayé avec Assert.True(true)!)
• exécutés dans n'importe quel ordre
• descriptifs et indiquer le problème testé
• documentés (nom et/ou commentaire)
• non triviaux

De plus, ils doivent...

• couvrir plusieurs composants/fonctionnalités
• couvrir autant le back-end que le front-end
• couvrir les fonctionnalités clés de l'application

Le but n’est pas d’avoir une couverture complète, mais de démontrer que vous comprenez les différents types de tests et êtes capable de tester plusieurs scénarios.

attention

Vous devez inclure dans votre readme comment exécuter les tests. Ce guide doit indiquer comment installer, si nécessaire, la bibliothèque de tests, et comment exécuter les tests.

Modalités de remise

• Remis via Gitlab et Confluence
• Votre fichier de plan de tests et de récapitulatif dans une section Remise Finale de votre Confluence
• Une section Tests ou équivalent ajoutée au readme pour les précisions quant à l'exécution des tests
• À remettre avant le 3 mars 2026 23:59

Grille d'évaluation

Plan de test (semaine 3)

Critère	Points
Identification et pertinence des tests à effectuer	60%
Distribution backend/frontend et types de test	30%
Partage des responsabilités	10%

Tests (semaine 6)

Critère	Points
Mise à jour du plan de test	10%
Couverture, variété et pertinence des tests	20%
Qualité des tests	50%
Tests des correctifs en lien avec la revue de code	20%