Aller au contenu principal

Tests unitaires et Gitlab

Introduction​

Le but de ce laboratoire est de vous montrer par la pratique ce que nous avons appris à propos de Git, des tests unitaires et de la couverture de code.

Il est aussi intéressant de signaler que le code est fait en JavaScript et utilise la dernière version de NodeJS. Mais ne vous inquiétez pas ! Le laboratoire a été conçu en tenant compte que vous ne connaissez pas ce langage. Dans le laboratoire, vous devrez corriger des erreurs qui ont été ajoutées. Il vous suffira de lire les commentaires présents dans les fichiers pour supprimer les lignes erronées. En effet, la correction des erreurs devrait être faite par les développeurs.

N'oubliez pas que le "DevOps" n'est pas propre à un langage particulier. Vous auriez très bien pu avoir un laboratoire en Ruby, Java, Go, etc. Mais vous devriez être capables de mettre en place un système de "DevOps" efficace dans tous les cas.

Ce laboratoire sera découpé en étapes plus ou moins difficiles. Si vous prenez le temps de réaliser chaque étape avec attention, vous verrez que les concepts vus au cours seront plus clairs.

Etape 1: création du projet en local

Tout d'abord, nous allons créer notre projet. Pour cela, téléchargez ce zip et décompressez-le. Ce fichier zip contient un petit projet en NodeJS et nous permettra de travailler sur une base de code. Les fichiers contiennent des erreurs, c'est normal ! Nous les corrigerons au fur et à mesure.

Ouvrez VSCode et ouvrez le dossier décompressé via le menu:

Normalement, vous devriez voir les fichiers du projet. Maintenant, il faut créer un répertoire Git pour un projet déjà existant.

Pour cela, il faut initialiser le répertoire Git:

Dans un premier temps, nous allons ajouter 3 fichiers:

danger

Il est important de bien respecter ces consignes, sinon, vous risquez d'être perdus dans la suite du laboratoire. Et n'oubliez pas... si on est perdu, le mieux sera de recommencer du début...

Ensuite, nous faisons un premier commit (avec le message "Init"). Ce commit est en local uniquement ! Cependant, on veut que ce commit soit aussi en ligne pour que toute l'équipe puisse y accéder.

Cliquez sur ... à coté de SOURCE CONTROL et sélectionnez les 3 options:

Maintenant, direction Gitlab pour créer notre remote repository !

Etape 2: création du projet sur Gitlab​

Gitlab est une plateforme gratuite qui propose des services payants pour les sociétés. Il est conseillé d'utiliser vos adresses étudiantes. Pour ce cours, l'offre gratuite sera largement suffisante 😊 Normalement, pour créer un projet, vous devriez arriver ici:

Créez un projet à partir de rien ("blank project") :

Choisissez le nom que vous voulez pour le projet. Le "projet slug" se mettra automatiquement à jour en fonction du nom, vous ne devez donc pas y toucher. Vérifiez bien que la visibilité de votre projet soit "privée" et que la case "Initialize repository with a README" ne soit pas cochée.

Vous devriez arriver ici:

Cliquez sur "Code" et copiez le texte en dessous de "Clone with SSH" (cette adresse ne fonctionne que pour SSH et c'est ce que nous allons utiliser).

Nous allons faire le lien entre notre répertoire local et distant dans VSCode. Retournez dans VSCode, cliquez sur les ... à côté de REPOSITORIES > Remote > Add Remote...

Collez l'URL que vous aviez prise sur Gitlab et voilà ! Maintenant, il ne reste plus qu'à tester que tout fonctionne. Retournez dans le menu à côté de REPOSITORIES, sélectionnez push et allez voir sur Gitlab si tout est bon.

Etape 2: Création des branches​

Nous allons protéger nos branches. En effet, nous souhaitons que les branches develop et main ne puissent plus être supprimées et que personne ne puisse envoyer du code directement dessus. Pour vous aider, vous trouverez la documentation à cette adresse (vous ne devez pas tout lire, la documentation va plus loin que nécessaire) : https://docs.gitlab.com/user/project/repository/branches/branch_rules

Vous devriez avoir ceci au final (il faut éditer la règle pour main et en créer une pour develop):

attention

Aucun push direct n'est autorisé sur develop et main.

Au niveau de Gitlab, vous pouvez créer directement des branches. C'est parfait, car nous venons de créer des règles pour protéger deux branches spécifiques. main existe déjà, mais ce n'est pas le cas de develop. Du coup, à vous de la créer maintenant à partir de main !

Maintenant, on retourne dans VSCode, car on voudrait envoyer notre première fonctionnalité (la suite de Fibonacci) en ligne. Toujours dans le menu REPOSITORIES, créez une nouvelle branche nommée Fibonacci. Ensuite, sélectionnez les deux fichiers liés à Fibonacci et faites un commit (exemple de message: "Add Fibonacci"). Enfin, faites un push et normalement tout est bon !

Alors que s'est-il passé ? Votre client Git a vu qu'aucune branche Fibonacci n'existait sur le répertoire distant (Gitlab) et l'a donc créée pour vous automatiquement. Pour voir si tout est bon, rendez-vous sur Gitlab et sélectionnez la branche... Fibonacci (logique) et vous devriez voir les nouveaux fichiers.

Etape 3: Notre première merge request​

Reprenons: nous avons 3 branches sur notre répertoire Gitlab: main, develop et Fibonacci. Maintenant, nous désirons fusionner Fibonacci, qui est une branche de fonctionnalité (souvenez-vous du workflow vu en classe), avec develop. Nous devons donc créer une merge request !

Nous allons créer notre première merge request pour ajouter les modifications de la branche Fibonacci à develop. Rendez-vous sur la page de votre repository, dans le menu à gauche, cliquez sur Code pour faire dérouler le menu. Sélectionner "Merge requests" pour arriver sur la page désirée.

Quand vous allez créer la merge request, pensez à bien vérifier que la branche fibonacci est bien la branche source et que la branche develop soit bien la branche cible ! Avant de valider votre merge request, cochez la case "Delete source branch when merge request is accepted.". En effet, cette branche ne nous sera plus utile par la suite et donc nous pouvons la supprimer.

Vous devriez arriver sur une page permettant de réaliser votre merge request.

Félicitation, votre première merge request sur Gitlab est faite !

Maintenant, on souhaite que ces changements se répercutent sur notre ordinateur. En effet, tout a été fait sur Gitlab, mais notre ordinateur ignore que la branche Fibonacci a été supprimée et que son contenu se retrouve dans la branche develop. Si on ne fait rien, on risque de continuer de travail sur la branche Fibonnaci et de push les changements à nouveau sur cette branche (et donc de recréer cette branche). Nous devons donc synchroniser notre répertoire local avec celui distant (le remote, aka Gitlab).

D'abord, faisons un checkout sur develop (dans le menu, choisissez Checkout to...). Sélectionnez la branche develop et faites un pull (toujours via le menu). Vous verrez que le graphique représentant l'historique de votre git a été mis à jour et nous voyons que la branche Fibonacci a été supprimée suite à une fusion.

Exercice 1: notre premier .gitlab-ci.yml​

Nous allons enfin mettre en place un système automatique de tests unitaires ! Gitlab utilise des images dockers pour exécuter votre code. Les instructions dans le fichier .gitlab-ci.yml permettent de créer des jobs dans des stages qui sont exécutés (en parallèle, les uns après les autres, sur certaines branches, etc). Vous pouvez utiliser un template "NodeJS" pour vous aider, mais sachez que la plupart des lignes proposées sont inutiles (le laboratoire est beaucoup trop simple pour le système proposé). Vous devrez donc comprendre comment fonctionne ce fichier et pour cela, vous devrez lire un peu de documentation :

  1. https://docs.gitlab.com/ci/ (utile seulement comme introduction sur les concepts)
  2. https://docs.gitlab.com/ci/quick_start/ (utile pour cerner le fonctionnement global).
  3. https://docs.gitlab.com/ci/yaml/ (documentation concernant le fichier .gitlab-ci.yml)

Un bon point de départ serait donc de partir du template et de lire la documentation du point 3 pour comprendre le fichier qui vous a été proposé. Ainsi, vous pourrez supprimer les lignes inutiles.

Pour réaliser l'exercice, créez une branche dédiée à l'ajout de ce fichier (dans mon cas, je l'ai appelée cicd). N'oubliez pas de fusionner les changements dans develop quand tout fonctionnera.

attention

Pour rappel, vous devriez voir des erreurs dans les logs des jobs ! C'est normal !

info

Dans un souci de simplicité, vous devrez exécuter un unique stage nommé test sur toutes les branches sauf la branche main (ce choix serait discutable pour un véritable environnement de production). Vous devez savoir deux choses :

  • Avant de lancer les tests, vous devez avoir installé les modules pour le projet. Ceci est possible via une commande : npm install
  • Pour lancer les tests, vous devez le faire via la commande npm run test

Si votre fichier .gitlab-ci.yml est bien écrit, les tests devraient se lancer automatiquement. Créez une merge request de votre branche contenant le fichier de configuration vers la branche develop. Dans votre merge request, vous devriez voir une indication à ce sujet:

En suivant les liens, vous devriez voir les logs de votre pipeline défiler ou, si vous êtes trop lents, voir les logs finaux.

Si jamais vous désirez voir tous les pipelines de votre projet, il est possible d'avoir la liste complète via le menu de gauche. Cliquez sur "Build", puis sur "Pipelines".

Fusionnez la branche avec develop et nous allons nous atteler à corriger ces bugs !

danger

Mais pourquoi fusionner la branche si tout clignote rouge ?!

Bonne remarque ! Nous devons d'abord nous poser la question: qu'est-ce qui ne va pas ? C'est le code fourni qui ne fonctionne pas. Notre pipeline fonctionne parfaitement puisqu'il exécute les tests. Quel était le but de notre branche cicd ? Créer un pipeline fonctionnel ! Ce qui est le cas et donc, nous pouvons fusionner notre branche à develop.

Exercice 2: corriger les erreurs​

Il est temps de chasser les erreurs de notre code !

Créez une branche fix-fibonacci. Faites une modification pour supprimer une seule erreur.

info

Une ligne qui commence par // est une ligne de commentaires en JavaScript.

Retournez voir les logs et vous devriez voir le nombre d'erreurs diminué. Ne fusionnez pas encore la branche ! Répétez cette opération pour corriger les erreurs une par une (allez voir les logs à chaque fois) et vous devriez réussir tous les tests à la fin !

attention

N'oubliez pas que la merge request devra cibler la branche develop et faites-le une fois toutes les erreurs corrigées.

Exercice 2.5: couverture des tests​

On aimerait connaître le pourcentage de code couvert par nos tests. Gitlab nous permet de rajouter cette information directement dans l'interface du site. L'unique condition est de lui préciser comment récupérer cette information depuis les logs.

Créez une branche coverage et faites-y les modifications nécessaires.

info

Un bon point de départ serait de commencer à lire la documentation avec les mots-clés du fichier .gitlab-ci.yml. Vous devriez y trouver les instructions nécessaires et des liens vers des pages complémentaires.

Vous aurez aussi besoin de modifier la configuration de notre projet qui ne calcule aucun coverage pour l'instant. Modifiez le fichier package.json:

package.json
{
  "name": "fibonacci",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "type": "module",
  "scripts": {
    "test": "vitest run --coverage"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "@vitest/coverage-istanbul": "^2.1.8",
    "vitest": "^2.1.8"
  }
}

Normalement, vous devriez voir ceci si tout fonctionne:

attention

N'oubliez pas que la merge request devra cibler la branche develop.

Exercice 3: le reste du code​

Nous souhaitons rajouter deux suites mathématiques à notre projet: celle de Padovan et celle de Syracuse. Commençons par créer la première !

Crééons la branche Padovan tout d'abord en envoyant les deux fichiers associés sur Gitlab. Vous devriez avoir ceci sur la plateforme en ligne:

N'oubliez pas de faire les corrections nécessaires et normalement, vous aurez à nouveau les tests qui fonctionnent:

attention

N'oubliez pas de faire les merge requests nécessaires. Dorénavant, elles ne vous seront plus rappelées.

Enfin, faites de même pour Syracuse et vous aurez terminé cet exercice.

Exercice 4: vers main et au-delà !​

Il ne nous reste plus qu'à envoyer l'ensemble de notre travail (depuis develop) vers la branche main ! Après toutes ces merge requests, vous ne devriez avoir aucune difficulté ! On pourrait dire que le laboratoire est terminé...

Il existe un moyen d'afficher des badges sur les pages des projets, comme ici avec le projet Gitlab

Je vous propose de faire pareil avec notre projet ! Il nous faudrait un badge indiquant le pourcentage de coverage (depuis la branche develop) de notre projet. Voici un petit lien qui devrait vous aider: https://docs.gitlab.com/user/project/badges/

À la fin, vous devriez avoir ceci:

Conclusion​

Vous comprenez les bases de l'automatisation des tests ainsi que le coverage associé. Vous avez pu visualiser l'importance de ces tests en vous rendant compte que les erreurs apparaissaient avant tout merge dans la branche develop. Ainsi, un développeur peut directement voir si les commits proposés poseront un problème sans avoir regardé le code !

Vous avez terminé (pour de bon) avec le laboratoire ;)