Skip to content

J1.md

Latest commit

 

History

History
161 lines (110 loc) · 8.31 KB

J1.md

File metadata and controls

161 lines (110 loc) · 8.31 KB
Raw

Jour 1 : tests automatisés et premier pipeline

Objectif de la journée : partir d'une application qui « a l'air de marcher », prouver par des tests qu'elle contient un bug, le corriger, puis faire vérifier chaque git push automatiquement par GitHub Actions.

1. Préparer votre dépôt

Votre poste de travail pour la semaine est le lab Atelier projet DevOps du Range : une machine Linux avec Node.js 24, Git, Docker et l'éditeur nano, que vous ouvrez chaque après-midi. La machine est neuve à chaque ouverture : seul ce que vous avez poussé sur GitHub est conservé.

  1. Sur votre ordinateur, connectez-vous à GitHub et ouvrez https://github.com/Neo-Cyber-Camp/devops-tasktracker.
  2. Cliquez sur Fork, gardez le nom proposé, validez. Le fork est votre dépôt personnel pour toute la semaine.
  3. Sur le Range, ouvrez le lab Atelier projet DevOps (chapitre 1 du module). Un seul lab peut être actif à la fois : si le Range indique qu'un autre lab est déjà actif, cliquez d'abord sur Terminer dans le lab du matin.
  4. Dans la console de l'Atelier, tapez ces commandes une par une :
atelier-init
cd ~/devops-tasktracker
git remote -v
npm test

atelier-init vous guide : appuyez sur Entrée à chaque question de la console et, quand un code de 8 caractères s'affiche, ouvrez https://github.com/login/device sur votre ordinateur, tapez ce code, puis cliquez sur Authorize. La commande connecte alors la machine à votre compte GitHub, clone votre fork dans ~/devops-tasktracker, ajoute la remote upstream (le dépôt du cours) et installe les dépendances (npm ci), puis affiche une ligne qui commence par Prêt. avec votre dernier commit.

Toutes les commandes du cours se lancent dans ~/devops-tasktracker, et git push ne vous demande pas de mot de passe après atelier-init. L'éditeur de l'Atelier est nano : le guide du lab contient l'aide-mémoire de ses raccourcis. Chaque après-midi, sur la machine neuve, relancez atelier-init (un nouveau code vous sera demandé).

Votre ordinateur reste utilisable si Node.js 24, Git et Docker y sont installés, mais il n'est pas pris en charge pendant les séances : en cas de problème, revenez à l'Atelier.

Résultat attendu : git remote -v affiche origin (votre fork) et upstream (le cours) ; npm test affiche 10 tests au vert.

2. Lire le code métier

Ouvrez src/tasks/service.js. Il exporte cinq fonctions : createTask, listTasks, updateTask, deleteTask et countByStatus. Ouvrez ensuite tests/service.test.js.

Résultat attendu : vous constatez que seules createTask et deleteTask sont testées. Trois fonctions sur cinq n'ont aucun test : si elles sont fausses, rien ne vous le dira.

3. Écrire les tests manquants

Ajoutez dans tests/service.test.js au minimum :

Fonction Cas à tester
listTasks sans filtre ; avec { done: true } ; avec { done: false }
updateTask changement de titre ; passage à done: true ; done qui n'est pas un booléen (doit lever une erreur) ; id inconnu (renvoie null)
countByStatus liste vide ; mélange de tâches terminées et à faire

Et dans tests/app.test.js, un test de la route GET /stats.

Squelette d'un test asynchrone :

describe('countByStatus', () => {
  test('compte les tâches terminées et à faire', async () => {
    // 1. préparer : créer des tâches avec service.createTask, en terminer une avec service.updateTask
    // 2. agir : appeler service.countByStatus(repo)
    // 3. vérifier : expect(resultat).toEqual({ done: ..., todo: ... })
  });
});

Rappel : toBe compare une valeur simple (nombre, texte, booléen) ; toEqual compare le contenu d'un objet ou d'un tableau.

Résultat attendu : au moins 20 tests, et au moins un test rouge.

4. Un test échoue : trouvez le bug

Un test rouge dont l'attente est juste signifie que le code est faux, pas le test. Lisez le message de Jest : il affiche la valeur attendue et la valeur reçue.

Indice si vous bloquez : relisez countByStatus et demandez-vous quel est le type de task.done. Un booléen true et le texte 'true' ne sont pas égaux avec ===.

Corrigez le code, relancez npm test.

Résultat attendu : tous les tests au vert.

5. Mesurer la couverture

npx jest --coverage

Visez au moins 80 % de lignes couvertes dans src/tasks/service.js, le code métier que vous testez aujourd'hui. pgRepository.js n'est pas concerné : il parle à PostgreSQL, que les tests unitaires n'utilisent pas. Gardez en tête ce que la couverture ne dit pas : une ligne exécutée par un test sans expect compte comme couverte, alors que rien n'a été vérifié.

Résultat attendu : service.js à 80 % de lignes ou plus.

6. Premier workflow GitHub Actions

Créez le fichier .github/workflows/ci.yml pour que GitHub, à chaque push et à chaque pull request :

  1. récupère le code (actions/checkout@v7) ;
  2. installe Node.js 24 avec le cache npm (actions/setup-node@v7, node-version: 24, cache: npm) ;
  3. lance npm ci, puis npm run lint, puis npm test.

Vous l'avez déjà écrit ce matin dans le lab creer-premier-workflow. Si vous bloquez, voici le fichier de référence ; en YAML, l'indentation se fait avec des espaces, jamais des tabulations :

name: CI

on:
  push:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage
git add .
git commit -m "test: couvrir listTasks, updateTask, countByStatus et corriger countByStatus"
git push origin main

Ouvrez l'onglet Actions de votre fork. Pour un fork, GitHub n'exécute pas les workflows tant que vous ne les avez pas autorisés : si vous voyez le bandeau « Workflows aren't being run on this forked repository », cliquez sur I understand my workflows, go ahead and enable them, puis refaites un git push (un commit vide suffit : git commit --allow-empty -m "ci: relancer" && git push).

Résultat attendu : un run au vert, et une coche verte à côté de votre commit.

7. Casser pour comprendre

  1. Changez volontairement une valeur attendue dans un test, commitez, poussez.
  2. Observez le run rouge, ouvrez l'étape npm test et lisez le message d'erreur.
  3. Annulez le changement avec git revert --no-edit HEAD, puis poussez.

Résultat attendu : un run rouge puis un run vert. Vous venez de voir le rôle d'un pipeline : refuser un changement cassé avant qu'il n'arrive en production.

8. Utiliser l'IA avec esprit critique

Demandez à un assistant IA d'écrire un test supplémentaire pour updateTask. Avant de le garder, prouvez qu'il sert à quelque chose : cassez volontairement le code qu'il teste, et vérifiez que le test devient rouge. Un test qui reste vert quand le code est faux ne protège rien.

Résultat attendu : vous gardez le test seulement s'il échoue sur le code cassé.

9. Fin de journée

  • Au moins 20 tests au vert
  • Bug de countByStatus corrigé
  • Couverture de src/tasks/service.js à 80 % ou plus
  • Workflow ci.yml au vert sur main dans votre fork
  • git status propre (rien à committer) et git push fait, puis Évaluer et Terminer l'Atelier : ce qui n'est pas poussé est perdu

10. Rattrapage

Si vous n'avez pas terminé, récupérez la correction au début de l'Atelier du jour 2, après atelier-init, dans ~/devops-tasktracker. La branche start-jN n'existe dans le dépôt du cours qu'à partir du matin du jour N. Commencez par enregistrer votre travail, puis fusionnez-la en gardant sa version en cas de conflit, et créez un commit à vous :

git add -A
git commit -m "wip: avant rattrapage"      # ignorez le message si rien n'est à committer
git fetch upstream
git merge -X theirs --no-edit upstream/start-j2
git commit --allow-empty -m "rattrapage J2"
npm ci
npm test
git push origin main

-X theirs garde vos modifications qui n'entrent pas en conflit, et prend la version du cours là où vous aviez écrit la même chose différemment. Le commit vide rattrapage J2 garantit que votre fork contient au moins un commit à vous, même quand la fusion n'en crée aucun (votre main était resté identique à celui du cours).