Dans ce module, tu vas structurer la façon dont ton équipe va tester l’application. L’idée est de ne pas tester « au hasard », mais de définir une stratégie de tests claire et de coder de vrais tests unitaires pour les parties importantes de ton système.

Cette page t’explique ce que doit contenir ton document de stratégie de tests, quels types de tests sont attendus dans le cours, et ce qu’on attend concrètement en termes de tests unitaires pour ton application.

Le document de stratégie de tests

La stratégie de tests est un document que ton équipe doit créer (et maintenir) dans le dossier docs/ de votre dépôt Git. Il décrit comment vous comptez vérifier que votre application fonctionne correctement.

• Le document doit être compréhensible par quelqu’un qui n’a pas écrit le code (par exemple l’enseignant ou le client).
• Il doit être suffisamment concret pour guider la conception des tests (automatisés ou non).

Ta stratégie de tests doit au minimum répondre aux questions suivantes :

• Quelles parties de l’application sont les plus importantes ou les plus à risque (fonctionnalités critiques, règles métier complexes, etc.) ?
• Quels scénarios de tests allez-vous couvrir pour ces parties (cas « normaux », cas limites, cas d’erreur) ?
• Quels types de tests utiliserez-vous pour ces scénarios (tests unitaires, tests d’intégration, autres) ?
• Quels scénarios seront effectivement automatisés sous forme de tests unitaires ?

Scénarios de tests à décrire

Un scénario de test décrit une situation concrète que tu veux vérifier dans ton application. Il est généralement lié à une fonctionnalité ou à une user story de ton backlog.

• Pour chaque fonctionnalité importante, identifie quelques scénarios représentatifs (exemples typiques, cas limites, comportements en cas d’erreur).
• Pour chaque scénario, note au minimum : le contexte (pré-conditions), les actions effectuées, le résultat attendu.
• Indique, pour chaque scénario, s’il sera testé manuellement, par un test unitaire, par un test d’intégration ou par un autre type de test.
• Fais le lien avec ton backlog en indiquant à quelles user stories ou critères d’acceptation le scénario est associé.

Types de tests attendus dans le cours

Dans ce projet, on s’attend à ce que tu utilises au moins deux grandes familles de tests pour ton application.

• Tests unitaires :
  • Vérifient le comportement d’une petite unité de code (par exemple une fonction, une méthode, une classe) isolée du reste du système.
  • Sont rapides à exécuter et peuvent être lancés souvent (idéalement à chaque modification pertinente du code).
  • Sont particulièrement utiles pour les règles métier et les calculs.
• Tests d’intégration :
  • Vérifient que plusieurs composants fonctionnent bien ensemble (par exemple service + base de données, API + couche métier).
  • Ciblent des chemins critiques dans ton application (par exemple un scénario important de bout en bout).

Selon ton projet, tu peux aussi mentionner d’autres types de tests (tests d’interface graphique, tests de bout en bout, etc.), mais le cœur du cours reste les tests unitaires et certains tests d’intégration.

Coder des tests unitaires pour ton application

La stratégie de tests ne doit pas rester théorique : tu dois réellement coder des tests unitaires pour ton application. Ces tests font partie intégrante du livrable.

• Identifie, dans ta stratégie de tests, quelles parties de ton code seront couvertes par des tests unitaires (par exemple les règles métier les plus importantes).
• Crée un projet ou un dossier dédié aux tests (par exemple tests/) dans ton dépôt, si ce n’est pas déjà fait.
• Implémente des tests unitaires pour plusieurs scénarios décrits dans ta stratégie de tests (et non uniquement pour des cas « faciles »).
• Assure-toi que ces tests peuvent être exécutés facilement (par exemple via ton outil de développement ou une commande de test).

L’objectif n’est pas d’atteindre une couverture parfaite, mais de montrer que tu es capable de concevoir et d’implémenter des tests unitaires pertinents pour ton projet.

Faire évoluer ta stratégie de tests pendant le projet

Comme le dossier de conception, ta stratégie de tests est un document vivant. Elle doit évoluer au fur et à mesure que ton application se précise.

• Ajoute de nouveaux scénarios de tests quand tu implémentes de nouvelles fonctionnalités.
• Mets à jour le document quand tu découvres des bugs importants ou de nouveaux risques.
• Ajuste le type de tests prévu si tu réalises qu’un scénario doit être automatisé (par un test unitaire ou d’intégration) plutôt que testé manuellement.
• Pense à committer régulièrement les mises à jour de ta stratégie de tests dans docs/, au même titre que ton code.

Ce qui est attendu pour ce module

• Un document de stratégie de tests dans le dossier docs/, qui décrit vos scénarios de tests et les types de tests que vous allez utiliser.
• Un début de mise en œuvre de cette stratégie sous forme de tests unitaires codés pour votre application.
• Un lien clair entre certains scénarios de tests et des user stories / critères d’acceptation de votre backlog.