---
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.