Finish first version

.gitlab-ci.yml

@@ -10,12 +10,12 @@ stages:
   - Testing
 
 # Définition des Jobs
-pylint:
+lint:
   stage: Testing  # chaque Job est rattaché à une étape
   script:  # Ce sont les commandes qui seront lancées et qui feront fail le job si une erreur est renvoyée
     - pyflakes code/*.py
 
-unittest:
+test:
   stage: Testing  # On crée 2 jobs en parallèle dans la même étape
   script:
     - python code/tests.py
\ No newline at end of file

README.md

@@ -218,10 +218,10 @@ stages:
   - Testing
 
 # Définition des Jobs
-pylint:
-    stage: Lint  # chaque Job est rattaché à une étape
+lint:
+  stage: Testing  # chaque Job est rattaché à une étape
   script:  # Ce sont les commandes qui seront lancées et qui feront fail le job si une erreur est renvoyée
-        - pylint -d C0301 code/*.py
+    - pyflakes code/*.py
 ```
 
 ---
@@ -240,4 +240,30 @@ Sur l'interface graphique, tu peux voir dans ***CI/CD > Pipelines*** l'état de
 
 ### Ajout de tests unitaires
 
-Maintenant qu'on a une pipeline avec une étape de linting, on veut aller plus loin en rajoutant des tests unitaires. Un test unitaire est un test qui teste la réponse d'une fonction face à certains arguments. Les tests unitaires ont été écrits dans `code/tests.py`. Il n'y a donc plus qu'à écrire le job correspondant dans `.gitlab-ci.yml`.
\ No newline at end of file
+Maintenant qu'on a une pipeline avec une étape de linting, on veut aller plus loin en rajoutant des tests unitaires. Un test unitaire est un test qui teste la réponse d'une fonction face à certains arguments. Les tests unitaires ont été écrits dans `code/tests.py`. Il n'y a donc plus qu'à écrire le job correspondant à la suite du premier dans `.gitlab-ci.yml` :
+
+```YAML
+test:
+  stage: Testing  # On crée 2 jobs en parallèle dans la même étape
+  script:
+    - python code/tests.py
+```
+
+Après avoir commit et push le fichier `.gitlab-ci.yml` complété, la pipeline devrait maintenant avoir une étape mais avec 2 jobs. D'ailleurs, le job de test fail. Sauras-tu le corriger ?
+
+---
+**Indice :**
+
+En cliquant sur ***CI/CD > Jobs*** et sur le job qui fail tu peux voir les logs. Ils contiennent surement des infos sur les erreurs.
+
+---
+
+## Conclusion
+
+Ça y est c'est la fin de ce TP. Bien sûr il n'a abordé qu'une faible partie de toute la puissance de Git mais j'espère qu'il t'a donné les clés pour survivre à l'utilisation de Git pour les Coding Weeks. La partie tests unitaires est un bonus mais qui peut rapporter très gros à la valeur d'un projet de Coding Weeks.
+
+Enfin, dernier conseil : Git réserve parfois quelques situations un peu complexes, notamment lorsque des conflits se créent entre deux modifications. Il faut alors les résoudre à la main (heureusement VSCode aide en affichant les conflits). Mais surtout pas de panique ! Comme dans beaucoup de messages d'erreur, Git donne la démarche à suivre pour résoudre l'erreur dans le message d'erreur. Il faut donc bien faire attention à ce que Git te communique !
+
+Sur ce j'espère que tu as apprécié ce TP, il ne me reste plus qu'à te souhaiter une bonne utilisation de Git en Coding Weeks ou pour le site de ton asso :wink: !
+
+Fabien ~ Coshyperbolix, pour ViaRézo.
\ No newline at end of file

code/tests.py

@@ -11,7 +11,7 @@ class TestFunctions(unittest.TestCase):
         self.assertEqual(translate('sourire'), ':smiley:')
         self.assertEqual(translate('pasdansledictionnaire'),
                          'pasdansledictionnaire')
-        #self.assertEqual(translate('casseletest'), 'letestcasse')
+        self.assertEqual(translate('casseletest'), 'letestcasse')
 
     def test_convert(self):
         self.assertEqual(convert('pasdansledictionnaire'),