Лист за преговор: Introduction au TDD et Tests Automatisés

📋 Plan du Cours

1. Test Driven Development et risques sans tests
2. Principe TDD avec cas concret et attentes
3. Jest pour exécuter automatiquement les fichiers de test
4. Organisation des tests et valeurs en dur
5. Dépendances de développement et production
6. Tests back-end avec Supertest et requêtes
7. Assertions Jest et vérification de clés du body
8. Clean Code pour un code lisible et débuggable
9. Déstructuration de tableau et d objet
10. Réduction des conditions avec opérateurs logiques
11. Opérateur ternaire pour remplacer les if else

📖 1. Test Driven Development et risques sans tests

🔑 Notions clés & Définitions

• Test Driven Development : Le Test Driven Development est une méthode où l’on écrit d’abord un test pour un cas concret, puis on développe la fonctionnalité pour le faire passer.
• Fichier de test : Un fichier de test est un fichier dédié qui regroupe des tests pour une fonctionnalité ou un sujet, par exemple basket.test.js.
• Framework de test : Un framework de test est un outil qui exécute automatiquement des fichiers de test et signale si les assertions passent ou échouent.
• Jest : Jest est une librairie/framework de test JavaScript qui détecte et exécute les fichiers de test pour valider le code.
• devDependencies : Les devDependencies sont des dépendances installées pour le développement et invisibles en production, contrairement aux dépendances classiques.

📝 Points essentiels

• Sans tests, une fonctionnalité peut être mal développée et oublier des aspects, ce qui peut aussi casser d’autres parties du site via les interactions.
• En TDD, on commence par écrire un test sur un exemple concret, puis on implémente la fonction pour que le test passe.
• Jest exécute automatiquement les fichiers de test détectés (ex. *.test.js) et indique si chaque test réussit ou échoue.
• Un fichier de test peut contenir autant de tests que nécessaire, souvent regroupés par sujet ou fonctionnalité.
• Les dépendances de développement (devDependencies) servent uniquement pendant la phase de développement et ne sont pas destinées à l’exécution en production.
• Pour exécuter les tests avec Jest, on lance la commande Yarn Jest et un échec affiche la ligne du test concernée.

💡 Astuce mémo

TDD = Test d’abord → Code ensuite : si le test passe, la fonctionnalité est validée.

📖 2. Principe TDD avec cas concret et attentes

🔑 Notions clés & Définitions

• TDD : Approche de développement où l’on écrit d’abord les tests, puis on code pour les faire passer.
• Supertest request : Outil Jest/Supertest qui permet d’appeler des routes HTTP depuis les tests.
• Jest toBe : Assertion Jest utilisée pour vérifier l’égalité stricte entre une valeur attendue et une valeur reçue.
• Jest toEqual : Assertion Jest utilisée pour vérifier l’égalité profonde de structures comme tableaux et objets.
• send (req.body) : Méthode Supertest qui envoie un objet dans le corps de la requête, correspondant à req.body côté serveur.

📝 Points essentiels

• Le test backend cible la racine de l’application, car c’est là que se connectent routers, modèles et logique centrale.
• Dans les tests, on importe l’app puis on utilise Supertest sous forme de request pour appeler les routes HTTP.
• Pour une route simple comme router.get /product, le test appelle directement cette route pour vérifier son comportement.
• Utilise toBe pour des valeurs simples (ex. chaîne, nombre) et toEqual pour des structures complexes (ex. Array, Objet).
• Avec une requête POST, la méthode send sert à fournir les données du corps, équivalentes à req.body.
• Si la route renvoie res.body.result, l’attendu du test doit vérifier la valeur dans la clé result.

💡 Astuce mémo

TDD = Test d’abord, puis code : Supertest appelle la route, toBe pour le simple, toEqual pour le complexe, send = req.body.

📖 3. Jest pour exécuter automatiquement les fichiers de test

🔑 Notions clés & Définitions

• Test Driven Development : Le Test Driven Development est une méthode où l’on écrit d’abord un test pour un cas précis, puis on développe la fonctionnalité pour le faire passer.
• Fichier .test.js : Un fichier .test.js est un fichier de test dont le nom se termine par .test.js pour être automatiquement détecté par la librairie de tests.
• Librairie de tests : Une librairie de tests est un outil qui repère les fichiers de test et exécute automatiquement les tests qu’ils contiennent.
• Exécution automatique des tests : L’exécution automatique des tests désigne le fait que les tests se lancent via l’outil, sans intervention manuelle à chaque fois.
• Fonction de test : Une fonction de test est un code qui vérifie qu’un résultat attendu est bien produit par la fonction à tester.

📝 Points essentiels

• Le TDD réduit le risque d’oublier des cas ou des vérifications en imposant un test avant d’implémenter la fonctionnalité.
• Sans TDD, une fonctionnalité peut être incorrecte (exemple de résultat doublé) ou retourner une valeur inattendue (exemple de valeur nulle).
• Sans TDD, une modification peut aussi casser une autre partie du site sans être détectée immédiatement.
• Un test décrit un cas concret et une attente explicite, par exemple un total de panier avec frais de port (exemple chiffré : 33).
• La librairie de tests exécute les fichiers dont le nom se termine par .test.js, comme dans le fonctionnement décrit avec ArianeTest.
• Lorsqu’on lance les tests, l’outil exécute les tests et renvoie un résultat indiquant si le développement est valide ou invalide.

💡 Astuce mémo

TDD = Test d’abord, Développement ensuite : le test dit “je veux tel résultat”, le code doit s’y plier.

📖 4. Organisation des tests et valeurs en dur

🔑 Notions clés & Définitions

• Framework de test : Un framework de test est une librairie qui exécute automatiquement des tests et affiche si le code respecte les attentes.
• Jest : Jest est un framework de test JavaScript utilisé pour lancer des tests unitaires et obtenir un rapport de réussite ou d’échec.
• Fichier .test.js : Un fichier .test.js est un fichier de test dont le nom permet à Jest de le détecter et de l’exécuter automatiquement.
• Test unitaire : Un test unitaire vérifie le comportement d’une fonction (ou d’un module) avec des entrées précises et des sorties attendues.
• Dépendance de développement : Une dépendance de développement est installée pour le travail en local (tests, outils) et n’est pas nécessaire au fonctionnement en production.

📝 Points essentiels

• Jest exécute automatiquement les fichiers de test détectés, puis indique quelles suites et quels tests passent ou échouent.
• Un test doit être basé sur un cas concret : on donne une entrée (ex. panier + frais) et on vérifie une sortie attendue.
• Le test ne doit pas vérifier la manière de faire (l’algorithme), mais le résultat final attendu pour les entrées données.
• Les fonctions testées doivent être exportées puis importées dans le fichier de test avec le bon nom, sinon le test échoue car la fonction n’est pas trouvée.
• Un exemple de test : deux items à 15 chacun avec 3 de frais de port doivent produire 33, et l’oubli des frais provoque un échec (attendu ≠ reçu).
• Le rapport Jest affiche une différence du type attendu vs reçu et pointe la ligne du test qui ne correspond pas à l’attente.

💡 Astuce mémo

Entrée → Sortie : le test dit « si je donne X, je veux Y », pas « comment tu fais ».

📖 5. Dépendances de développement et production

🔑 Notions clés & Définitions

• Dépendances : Les dépendances sont des modules nécessaires au projet, installés via le gestionnaire de paquets pour que le code puisse fonctionner.
• Dépendances de développement : Les dépendances de développement sont des modules utiles uniquement pendant la phase de développement et de test, pas pendant l’exécution en production.
• CORS : CORS est une dépendance qui permet d’autoriser des requêtes depuis des origines différentes (origins) vers ton API.
• Mongoose : Mongoose est une dépendance qui sert à interagir avec la base de données depuis le code applicatif.

📝 Points essentiels

• Les dépendances de production sont incluses dans le paquet utilisé quand le site tourne en hébergement et en utilisation réelle.
• Les devDependencies sont invisibles côté production : elles ne doivent pas être nécessaires au fonctionnement pour les utilisateurs.
• Dans un fichier de configuration de paquets, on distingue généralement dependencies et devDependencies pour séparer ce qui est requis en prod de ce qui sert au dev.
• Un exemple de devDependencies : les tests n’exécutent pas pendant l’usage par les utilisateurs, car ils servent à vérifier le code avant mise en ligne.
• Un test vérifie un cas particulier avec des valeurs en dur, contrairement à une fonction qui doit gérer des entrées variées.
• Avec Jest, les mots-clés comme expect et hit/it sont fournis par Jest et doivent être exécutés via Jest, pas directement dans le navigateur.

💡 Astuce mémo

Prod = modules pour tourner ; Dev = modules pour vérifier (tests).

📖 6. Tests back-end avec Supertest et requêtes

🔑 Notions clés & Définitions

• Supertest : Supertest est une librairie qui permet d’envoyer des requêtes HTTP à votre back-end depuis vos tests pour vérifier ses routes.
• App Express : L’app Express est le point d’entrée qui regroupe le routage et la configuration du back-end, et sert de base aux requêtes dans les tests.
• Requête GET : Une requête GET est une méthode HTTP utilisée pour récupérer une ressource via une route, par exemple sur le chemin /product.
• Async Await : Async/await est une syntaxe JavaScript qui simplifie l’attente de promesses en rendant le code de test plus lisible.
• Expect Jest : Un expect Jest est une assertion qui vérifie le résultat d’une exécution (valeur, type, existence) et fait échouer le test si la condition n’est pas satisfaite.

📝 Points essentiels

• Un test back-end passe par l’appel de routes, contrairement au front où l’on teste directement des fonctions ou composants.
• On peut écrire plusieurs expect dans un même test pour vérifier plusieurs aspects d’une réponse.
• Quand un test échoue, Jest affiche typiquement expected vs received pour aider à localiser l’erreur dans la logique.
• Supertest s’installe en dépendance de développement (devDependencies) car il sert uniquement pendant la phase de tests.
• Dans un test, on importe l’app puis on crée une requête Supertest sur la méthode et le chemin de la route (ex. app.get('/product')).
• Pour une route GET, on vérifie souvent le code HTTP via response.statusCode (ex. attendu 200).

💡 Astuce mémo

Supertest = Postman automatisé en code : app + méthode + chemin → réponse à vérifier avec expect.

📖 7. Assertions Jest et vérification de clés du body

🔑 Notions clés & Définitions

• expect : Assertion Jest qui vérifie qu’une valeur reçue correspond à ce que le test attend.
• toBe : Matcher Jest pour comparer une valeur simple avec une égalité stricte.
• toEqual : Matcher Jest pour comparer l’égalité de structures (tableaux, objets) en vérifiant leur contenu.
• REST.status code : Champ de la réponse HTTP renvoyé par Supertest, utilisé pour vérifier que la requête a réussi (ex. 200).
• rest.body : Champ de la réponse HTTP contenant le JSON renvoyé par l’API, utilisé pour vérifier des clés précises.

📝 Points essentiels

• Supertest permet d’exécuter une requête vers l’app et d’attendre la réponse sur le bon chemin (ex. GET /product).
• Un test de route GET commence souvent par vérifier que REST.status code vaut 200 pour confirmer le succès HTTP.
• Pour les valeurs simples (string, number, bool), utilisez toBe afin de vérifier l’égalité stricte attendue.
• Pour les structures complexes (Array, Objet), utilisez toEqual pour comparer le contenu plutôt que la référence.
• rest.body correspond au JSON envoyé par le serveur via rest.json, donc on peut vérifier une clé précise comme rest.body.stock ou rest.body.result.
• Pour une requête POST avec données, utilisez send(...) pour envoyer un objet en body (ex. { email, password }).

💡 Astuce mémo

toBe = simple (égalité stricte) ; toEqual = structure (égalité de contenu).

📖 8. Clean Code pour un code lisible et débuggable

🔑 Notions clés & Définitions

• Clean Code : Clean Code désigne un ensemble de pratiques et conventions visant un code uniforme, lisible et plus facile à comprendre et à débugger.
• Lisibilité : La lisibilité est la qualité d’un code qui se comprend rapidement grâce à une structure claire et un style cohérent.
• Code bien construit : Un code bien construit est organisé en blocs et en fonctions cohérents pour faciliter la lecture, la maintenance et le débogage.
• Factorisation : La factorisation consiste à éviter la duplication en regroupant le même comportement dans un endroit réutilisable.
• Données configurables : Les données configurables sont des valeurs (comme des clés ou des adresses) stockées pour être modifiées facilement sans toucher au reste du code.

📝 Points essentiels

• Clean Code vise un code plus intelligible, plus uniforme et plus simple à débugger grâce à des conventions partagées.
• Trois principes de base sont mis en avant : lisible, bien construit, et factorisé.
• Dupliquer une fonction dans plusieurs endroits et l’exporter/importer depuis un module fait le même travail fonctionnel, mais l’import rend la maintenance plus simple.
• Si une valeur change (ex. clé API révoquée), la factorisation via une variable unique évite de devoir modifier toutes les occurrences.
• Stocker des constantes d’environnement (ex. localhost 3000) dans une variable permet de changer la valeur lors d’un déploiement sans parcourir tous les fichiers.
• Réduire le nombre de conditions : une comparaison renvoie déjà vrai/faux, donc on peut assigner directement le résultat plutôt que d’écrire un if qui affecte true/false.

💡 Astuce mémo

Lisible-Bien construit-Factorisé : si ça change, ça change en un seul endroit.

📖 9. Déstructuration de tableau et d objet

🔑 Notions clés & Définitions

• Déstructuration de tableau : Technique JavaScript qui extrait des éléments d’un tableau vers des variables via une syntaxe en crochets.
• Déstructuration d objet : Technique JavaScript qui extrait des propriétés d’un objet vers des variables via une syntaxe en accolades.
• Constante const : Déclaration JavaScript qui empêche la réassignation de la variable, ce qui réduit les erreurs liées aux modifications.
• Opérateurs logiques : Opérateurs comme ET et OU utilisés pour combiner des conditions dans des structures conditionnelles.

📝 Points essentiels

• Avec const, si vous ne réassignez jamais une variable, vous verrouillez la valeur et limitez les erreurs de réaffectation.
• Un ET logique dans une condition ne déclenche l’exécution que si toutes les conditions sont vraies.
• Un OU logique dans une condition déclenche si au moins une condition est vraie, sans exiger que les autres le soient.
• La déstructuration de tableau assigne les variables selon la position des éléments (l’ordre compte).
• La déstructuration d objet assigne les variables selon les noms des propriétés (le nom compte).
• Si une propriété n’existe pas dans l’objet, vous ne pouvez pas la déstructurer (elle ne sera pas récupérable).

💡 Astuce mémo

Tableau = POSITION (item1, item2) ; Objet = NOM (user.name → name).

📖 10. Réduction des conditions avec opérateurs logiques

🔑 Notions clés & Définitions

• Déstructuration d'objet : La déstructuration d'objet permet d'extraire des propriétés d'un objet en variables, à condition que les clés existent réellement dans l'objet.
• Opérateurs logiques : Les opérateurs logiques servent à combiner des conditions pour choisir une valeur ou un chemin d'exécution plus simplement.
• Valeurs par défaut de paramètres : Les valeurs par défaut permettent à une fonction d'utiliser automatiquement une valeur quand un argument est absent ou non fourni.
• Paramètre objet unique : Un paramètre objet unique regroupe plusieurs champs (nom, âge, email, etc.) pour rendre l'appel plus clair et éviter d'oublier des arguments.
• Méthodes JavaScript natives : Les méthodes natives comme map, filter, find, include, reduce sont des outils standard pour transformer ou rechercher des données.

📝 Points essentiels

• On ne peut déstructurer que les clés réellement présentes dans l'objet, sinon les propriétés demandées n'existent pas.
• Si une variable et une clé ont le même nom (ex. name), la déstructuration peut se faire directement sans renommage explicite.
• Pour réduire la complexité, on peut regrouper des champs dans un objet puis déstructurer en une ligne à l’intérieur de la fonction.
• Un paramètre non fourni vaut souvent undefined, ce qui permet de déclencher une valeur par défaut (ex. false pour un booléen).
• Les valeurs par défaut dans la signature sont plus simples que tester explicitement undefined dans le corps de la fonction.
• Quand une fonction dépasse ~3 arguments, il vaut mieux passer un seul objet (user) plutôt que plusieurs paramètres séparés pour améliorer la lisibilité et la robustesse du code.

💡 Astuce mémo

Déstructurer = clés existantes ; défaut = undefined → valeur prévue ; >3 arguments → 1 objet.

📖 11. Opérateur ternaire pour remplacer les if else

🔑 Notions clés & Définitions

• Opérateur ternaire : Opérateur JavaScript qui remplace un if-else en choisissant entre deux expressions selon une condition booléenne.
• Condition booléenne : Expression qui s’évalue en vrai ou faux et pilote le choix de la branche dans un opérateur ternaire.
• Syntaxe condition ? vrai : faux : Forme ternaire où la condition précède le point d’interrogation et les deux branches sont séparées par les deux-points.
• return ternaire : Usage du ternaire pour renvoyer directement une valeur, en mettant le return devant l’expression complète.
• Spread operator : Opérateur JavaScript noté avec trois points qui étale les éléments d’un tableau dans une autre structure.

📝 Points essentiels

• Un opérateur ternaire s’écrit condition ? expressionVraie : expressionFausse et remplace un if-else simple.
• La condition doit être évaluée en vrai/faux, et on peut omettre le true explicite si la condition renvoie déjà un booléen.
• Les deux branches après les deux-points sont obligatoires : un ternaire incomplet ne fonctionne pas.
• Pour retourner une valeur, on met un seul return devant le ternaire : return (condition ? valeur1 : valeur2).
• Si on met return séparément dans chaque branche, le code peut devenir invalide ou provoquer un crash selon la structure écrite.
• Le spread operator fusionne des tableaux au niveau de la liste d’éléments, mais sans spread on obtient souvent un tableau de tableaux (structure imbriquée).

💡 Astuce mémo

Ternaire = Question ? Oui : Non (et pour return : return devant tout le ternaire).

📊 Tableaux de synthèse

toBe vs toEqual (Jest)

Type de valeur	Matcher Jest	But
Valeur simple (string, number, bool)	toBe	Vérifier l’égalité stricte attendue vs reçue
Structure complexe (Array, Objet)	toEqual	Vérifier l’égalité de contenu (pas la référence)

⚠️ Pièges & confusions fréquents

1. Confondre toBe et toEqual : utiliser toBe pour un objet/Array fait échouer le test même si le contenu semble identique.
2. Oublier que le test vérifie un cas particulier avec des valeurs en dur : croire qu’un test “passe” pour un jeu de données garantit tous les autres.
3. Ne pas exporter/importer la fonction testée avec le bon nom : le test échoue car la fonction n’est pas trouvée.
4. Tester une route back-end comme une fonction front : sur back-end, il faut appeler les routes via Supertest (app + méthode + chemin).
5. Vérifier le mauvais champ du body : confondre la clé attendue (ex. result/stock) ou tester le body entier au lieu d’une clé précise.
6. Installer Jest/Supertest en dependencies au lieu de devDependencies : les tests deviennent inutiles en production et peuvent alourdir l’exécution.
7. Écrire des tests en dehors de Jest : utiliser expect/it dans le navigateur sans exécution via Jest provoque des erreurs (undefined).

✅ Checklist Examen

1. Expliquer le principe TDD : écrire un test sur un cas concret, puis développer la fonctionnalité pour le faire passer.
2. Savoir décrire le rôle d’un fichier de test nommé *.test.js et le fait que Jest les détecte et exécute automatiquement.
3. Distinguer dependencies vs devDependencies : devDependencies servent aux tests/développement et ne doivent pas être nécessaires en production.
4. Choisir le bon matcher Jest : toBe pour valeurs simples et toEqual pour Array/Objet (égalité de contenu).
5. Pour un test front/unit : formuler l’attendu “entrée → sortie” et vérifier le résultat final, pas l’algorithme.
6. Pour un test back-end : importer l’app Express (racine) et utiliser Supertest pour appeler la route (méthode HTTP + chemin).
7. Vérifier le succès HTTP avec REST.statusCode (ex. 200) avant de vérifier le contenu du body.
8. Pour une route GET : vérifier une clé précise dans rest.body (ex. stock) avec toBe/toEqual selon le type.
9. Pour une route POST : envoyer des données avec send(...) et vérifier une clé précise du JSON renvoyé (ex. rest.body.result).
10. Savoir que un test peut contenir plusieurs expect pour vérifier plusieurs aspects d’une même réponse.
11. Décrire le comportement de Jest en cas d’échec : il affiche expected vs received et pointe la ligne du test concerné.
12. Rappeler les règles Clean Code vues : données configurables (const/variables), réduire les conditions, factoriser, et utiliser la déstructuration selon tableau (position) vs objet (nom).