Le programmeur n’est pas le seul acteur à participer à l’élaboration du code source.
Il y a aussi le testeur.
Le testeur réceptionne le code source et le soumet à une batterie de tests pour s’assurer qu’il corresponde bien aux spécifications requises.
Nous allons, pour illustrer les tests, construire une horloge et nous assurer qu’elle indique bien l’heure exacte.
Notre programmeur a rédigé une horloge lunaire.
Pour qu’elle fonctionne,
il faut lui donner le TimeStamp Java en millisecondes de l’instant souhaité.
Cet objet se comporte grosso modo comme une fonction.
Son mutateur getPhase() rend l’angle de phase de la lune en radians.
Code source
La classe d’accueil
L’horloge à tester
Pour effectuer nos tests, nous n’avons pas besoin de savoir comment cette horloge fonctionne.
Nous allons juste l’interpeller de l’extérieur.
Ne vous fatiguez donc pas à en comprendre le code source !
Le cercle trigonométrique pointé à droite, de rayon unitaire.
Les angles sont mesurés en radian :
| Radians | Degrés | Phase lunaire | Position |
|---|---|---|---|
| 0 | 0° | nouvelle lune | à droite |
| Pi / 2 | 90° | premier quartier | en haut |
| Pi | 180° | pleine lune | à gauche |
| 3 PI / 2 | 270° | dernier quartier | en bas |
Le sinus se mesure sur l’axe vertical. 1 au-dessus, -1 en dessous.
Le cosinus se mesure sur l’axe horizontal. 1 à droite, -1 à gauche.
Pour tester une phase, on règle l’horloge à la date voulue, puis on teste le sinus ou le cosinus de l’angle de phase.
Ca laisse une tolérance par rapport à une valeur angulaire exacte.
Par exemple, la lune sera considérée comme pleine si son cosinus est inférieur à -0.98,
plutôt que d’exiger que son angle soit strictement égal à Pi / 2.
Attention au réglage des mois. 0 pour janvier, … 11 pour décembre.
Ouvrez ensuite le test TestHorloge.java.
Exécutez-le (ctrl-F11)
A gauche, à la place du volet dossiers, vous verrez le compte-rendu des tests sous forme d’une barre verte ou rouge.
Le test est une classe, qui, comme toute classe, peut comporter ses propres variables.
Une de ces variables est précisément un objet de la classe à tester.
Les procédures setUp() et tearDown() sont exécutées avant et après chaque test.
Par exemple, pour donner une valeur initiale à l’objet à tester.
Ensuite, toutes les procédures annotées @Test seront exécutées au titre de test.
Sauf celles suspendues par @Ignore, qui permet de suspendre un test.
Elles doivent se terminer par une assertion.
Ces assertions mentionnent l'expression qui doit être vraie, fausse, ou deux expressions qui doivent être égales.
Si tel est le cas, le test est réussi.
Nous pouvons, par exemple, tester que le débarquement de Normandie (6 juin 1944) a bien eu lieu une nuit de pleine lune.
Les classes font l’objet de fréquents remaniements.
Toute classe comporte une interface et une implémentation.
En principe, elle est manipulée de l’extérieur par son constructeur, ses getters et ses setters.
Une classe peut faire l’objet d'une refonte, partielle ou complète, de son implémentation,
sans modification de ses accesseurs (interface).
Après un tel remaniement, il peut être utile de vérifier si les valeurs qu’elle rend par ses getters
correspondent toujours bien aux valeurs attendues,
en fonction des valeurs confiées au constructeur ou aux setters.
Les test JUnit 4 sont là pour ça.
Amusez-vous maintenant à perturber l’horloge,
à modifier la durée d’une lunaison ou à en changer le point de départ, et vos test échoueront.