feat: add test lessons

content/conduite_projet/4_tests/index.md

@@ -0,0 +1,75 @@
+---
+title: "Conduite de projet: les tests"
+date: 2024-09-30
+tags: ["tests", agile"]
+categories: ["Conduite de projet", "Cours"]
+mathjax: true
+---
+
+Il existe plusieurs granularités et niveaux de tests. au plus haut niveau nous
+avons l'adéquation entre ce que l'utilisateur veut et ce qui est proposé.
+
+![Pyramides des tests](./imgs/pyramides_tests.svg)
+
+Les niveaux de tests peuvent être représentés sous la forme d'une pyramide, plus
+on monte:
+
+* plus les tests coûtent cher;
+* plus ils sont nombreux;
+* plus ils sont fragiles.
+
+Chaque unité de test dépends du contexte: procédure, fonction, méthode, classe.
+Chaque développeur a sa façon d'écrire des tests.
+
+Les tests ne doivent pas faire parti des éléments à tester, ils doivent seulement
+interagir avec eux.
+
+Nous avons:
+
+ * Les **tests unitaires ou de composants** qui servent à tester les bouts de codes;
+ * les **tests d'intégration** pour tester les intégrations de composants entre
+   eux.
+ * les **tests systèmes** au niveau le plus haut. permet de tester l'absence de bug au niveau de l'utilisateur
+
+
+## Les tests unitaires
+
+Ils doivent permettre d'améliorer la confiance accordée au code et agir comme
+garde-fou. Il permettent aussi de trouver les fautes le plus tôt possible. Les
+tests doivent être le plus léger possible, facile à lancer. Ainsi ils seront
+exécutés le plus souvent possible.
+
+De facto, ils deviennent des **test de non régressions**. Ainsi tout travail de
+refactorisation du code sera plus simple et plus confortable.
+
+### Tester quoi?
+
+En général, les fautes viennent des cas limites, nous voulons que **les
+résultats obtenus** soient égaut **aux résultats attendus**
+
+### Anomalies et bugs
+
+Une anomalie dans le code fait que notre programme ne fonctionne pas comme il le
+devrait, elle déclenche un bug.
+
+Un bon développeur ne doit pas avoir peur des anomalies et il doit pouvoir les
+fixer. Un **bon testeur** doit trouver ces anomalies. Comme nous l'avons vu, si
+`RO != RA` alors nous avond un bug. Pour le testeur, il faut préciser *l'état
+initial*, la *suite de traitement*, et *le résultat attendu*.
+
+### Les oracles
+
+Parfois, il n'est pas possible de définir les **cas aux limites**. Dans ce cas
+il est possible de passer par une **oracle**: une fonction test qui vérifie les
+sorties pour un ensemble de valeurs en entrée. Dans le cadre d'une fonction de
+tri, il est par exemple possible de créer une fonction qui définira une suite de
+nombres choisi aléatoirement en entrée et vérifiera la sortie.
+
+
+## Test d'intégration
+
+Ici nous testons les appels necessaires, il faut alors vérifier que nous n'avons pas d'erreurs et les valeurs qui nous sont retournées (validités du JSON par exemple).
+
+## Tests de validation
+
+Il faut "*scripter*" un scénario d'utilisation, définir le résultat attendu et le lancer et jouer notre scénario. Des outils spécialisés existent comme *Scelenium* pour tester les application web.