Tests unitaires
Page 1 sur 1
Tests unitaires
Bonjour à tous !
Il y a quelques semaines, j'ai ajouté un nouveau dossier au dépôt : le dossier "test".
Il contient ce qu'on appelle des "tests unitaires". Ils servent à s'assurer que le code fonctionne comme il se doit. Ce sont des petites fonctions regroupées en classes qui testent les différentes fonctionnalités du programme.
Ainsi, on peut savoir en moins d'une seconde quelles sont les fonctionnalités qui fonctionnent mal.
Note : pour exécuter ces tests, il suffit de faire un "make run". Sous eclipse, il faut lancer la classe test/AllTests.java.
Pour expliquer les tests unitaires, je vais me baser sur un exemple, écrit pour le projet : jeu.MessageTest (qui se trouve donc dans test/jeu/).
En voici un extrait :
Première chose qu'on remarque : la présence d'annotation @Test, qui permet à celui qui lance les tests (JUnit) de les repérer.
L'annotation @Before indique que la méthode setUp doit être exécutée à chaque lancement d'un test.
La méthode setUp créé deux objets Message : un message public et un privé (par rapport au constructeur, le privé possède l'argument "destinataire").
Le premier test est "getters", qui va tester la validité des getters. assertEquals est une fonction de JUnit : elle teste l'égalité des deux arguments, et s'ils sont différents, les tests s'arrêtent avec un message d'erreur, cela indique qu'une fonctionnalité est défaillante !
Le deuxième test est "privacy", qui vérifie qu'un message privé renvoie les bonnes valeurs aux appels de "isPrivate" et "isPublic", grace à assertTrue et assertFalse.
On a ici les principaux ingrédients d'un tests unitaires : une initialisation des paramètres, une éventuelle modification, puis quelques vérification de données/comportements.
Grace aux tests unitaires, on a d'avantage confiance envers le code (surtout quand ce n'est pas le notre), on sait qu'il fonctionne et comment l'utiliser ! Ici par exemple, on sait que "isPrivate" renvoit vrai dans le cas d'un message privée (même si ça paraissait assez évident compte tenu du nom de la méthode), on a pas besoin d'aller regarder dans le code de Message.java voir comment ça fonctionne vraiment, l'important c'est que ça fonctionne.
Aussi, on va pouvoir modifier le code avec moins de craintes. Je m'explique : imaginez que vous avez implémenté certaines règles, mais que le code n'est pas très propre. Il faudrait le modifier, tout en gardant les fonctionnalités (faudrait pas tout casser).
Sans les tests unitaires, il faudrait tester en lancant l'application à chaque fois (serveur + client) et répéter les mêmes actions pour tester les règles implémentées.
Avec les tests unitaires, vous aller pouvoir recoder certaines parties, et au fur et à mesure que vous le faite, vous savez exactement qu'elles fonctionnalités est encore cassée et lesquelles fonctionnent à nouveau.
Il est important de prendre du temps à rédiger des tests, il ne faut pas les négliger. S'ils sont bien fait, et qu'ils sont mis à jour régulièrement, alors ce n'est que bénéfique !
Je vous invite à regarder d'autres exemples de tests du projet. Pour le moment, il y a 49 tests dans le projet, qui testent en tout une dizaine de classes.
Il y a quelques semaines, j'ai ajouté un nouveau dossier au dépôt : le dossier "test".
Il contient ce qu'on appelle des "tests unitaires". Ils servent à s'assurer que le code fonctionne comme il se doit. Ce sont des petites fonctions regroupées en classes qui testent les différentes fonctionnalités du programme.
Ainsi, on peut savoir en moins d'une seconde quelles sont les fonctionnalités qui fonctionnent mal.
Note : pour exécuter ces tests, il suffit de faire un "make run". Sous eclipse, il faut lancer la classe test/AllTests.java.
Pour expliquer les tests unitaires, je vais me baser sur un exemple, écrit pour le projet : jeu.MessageTest (qui se trouve donc dans test/jeu/).
En voici un extrait :
- Code:
(les imports)
public class MessageTest {
Message privateMessage;
Message publicMessage;
@Before
public void setUp() {
publicMessage = new Message("nick", "content");
privateMessage = new Message("nick", "content", "to");
}
@Test
public void getters() {
assertEquals(privateMessage.getFrom(), "nick");
assertEquals(privateMessage.getContent(), "content");
assertEquals(privateMessage.getTo(), "to");
}
@Test
public void privacy() {
assertTrue(privateMessage.isPrivate());
assertFalse(privateMessage.isPublic());
}
etc.
Première chose qu'on remarque : la présence d'annotation @Test, qui permet à celui qui lance les tests (JUnit) de les repérer.
L'annotation @Before indique que la méthode setUp doit être exécutée à chaque lancement d'un test.
La méthode setUp créé deux objets Message : un message public et un privé (par rapport au constructeur, le privé possède l'argument "destinataire").
Le premier test est "getters", qui va tester la validité des getters. assertEquals est une fonction de JUnit : elle teste l'égalité des deux arguments, et s'ils sont différents, les tests s'arrêtent avec un message d'erreur, cela indique qu'une fonctionnalité est défaillante !
Le deuxième test est "privacy", qui vérifie qu'un message privé renvoie les bonnes valeurs aux appels de "isPrivate" et "isPublic", grace à assertTrue et assertFalse.
On a ici les principaux ingrédients d'un tests unitaires : une initialisation des paramètres, une éventuelle modification, puis quelques vérification de données/comportements.
Grace aux tests unitaires, on a d'avantage confiance envers le code (surtout quand ce n'est pas le notre), on sait qu'il fonctionne et comment l'utiliser ! Ici par exemple, on sait que "isPrivate" renvoit vrai dans le cas d'un message privée (même si ça paraissait assez évident compte tenu du nom de la méthode), on a pas besoin d'aller regarder dans le code de Message.java voir comment ça fonctionne vraiment, l'important c'est que ça fonctionne.
Aussi, on va pouvoir modifier le code avec moins de craintes. Je m'explique : imaginez que vous avez implémenté certaines règles, mais que le code n'est pas très propre. Il faudrait le modifier, tout en gardant les fonctionnalités (faudrait pas tout casser).
Sans les tests unitaires, il faudrait tester en lancant l'application à chaque fois (serveur + client) et répéter les mêmes actions pour tester les règles implémentées.
Avec les tests unitaires, vous aller pouvoir recoder certaines parties, et au fur et à mesure que vous le faite, vous savez exactement qu'elles fonctionnalités est encore cassée et lesquelles fonctionnent à nouveau.
Il est important de prendre du temps à rédiger des tests, il ne faut pas les négliger. S'ils sont bien fait, et qu'ils sont mis à jour régulièrement, alors ce n'est que bénéfique !
Je vous invite à regarder d'autres exemples de tests du projet. Pour le moment, il y a 49 tests dans le projet, qui testent en tout une dizaine de classes.
Jérémy- Analyste-programmeur
- Messages : 79
Feuille de personnage
Nom du personnage:
Page 1 sur 1
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum