Discussion :

[danyboy85]

Bonjour, dans le cadre de mon taf, on me demande d'utiliser le framework JUNIT (gestion des tests unitaires).

J'ai bien saisi l'intérêt d'utiliser ce genre de frameworks mais je ne vois pas comment m'en servir de facon intéressante.


En effet j'ai réalisé une petite appli de test ou je teste une méthode
"additionner (int, int)"

si je teste en faisant assertTrue(additioner(2,2)==4); --> le test se passe bien

si je teste en faisant assertTrue(additioner(2,2)==5); --> le test retourne une erreur.

bon, OK.

Mais j'ai du mal a saisir comment tester des trucs plus complexes.

Par exemple j'ai une méthode "getListeClients()" qui va chercher la liste des clients en base de donnée et qui les met dans un objet liste.

Qu'est ce que je dois tester ? Je ne vois pas quoi tester seulement avec
- assertTrue
- assertFalse
- assertBoolean
...

Quelqu'un peut-il m'éclairer ?

[ego]

A toi de voir !
Ex : Liste non vide, les objets sont-ils bien de type Client ?

Ensuite, si tu peux mettre des conditions sur le chargement des clients, il faut vérifier que les conditions sont effectivement respectées.

Des fois les test sont simples tu sais !

[danyboy85]

Bonjour, tu viens de me convaicre de ne pas utiliser JUNIT

En effet, je n'ai pas besoin d'un outil comme ca pour savoir si je passe les bons objets dans une liste ou si mes conditions sont respectées.
Ma liste a parfaitemenu le droit d'être vide.


Désolé je ne suis pas éclairé

[ego]

je n'ai fait que te donner des exemples !!
c'est à toi de mettre le code nécessaire pour vérifier qu'en fonction de conditions initiales que tu as définis, ton objet / opération fait ce qu'on lui demande.

Prenons un exemple très simple d'une opération qui fait l'addition de 2 nombres. Dans ton test, tu vas par exemple lui passer 4 et 5 et en sortie, tu vas vérifier qu'elle donne bien 9.
Autre exemple pour les tests aux limites, si tu as une opération qui fait la racine carré d'un nombre, tu peux lui passer un chiffre négatif et vérifier que l'opération te renvoie une exception (si c'est ce qui est prévu quand on passe un paramètre qui n'est pas dans l'ensemble des valeurs autorisées)

Saches que JUnit est énormement utilisé dans les projets Opensource et dasn pas mal d'entreprise alors c'est probablement que c'est utile !

[danyboy85]

En fait j'ai l'impression que tous les exemples donnés de l'utilisation de Junit ne sont pas concrets du tout.

Tu as dans une application une méthode qui attend deux entiers et qui renvoie un entier ? Moi jamais

Moi mes méthodes sont très souvent des "void" qui font des insertions en base de donnée ou qui instancient un Objet depuis une sélection dans un table.

Je n'ai pas de méthodes "mathématiques" comme ca

[danyboy85]

En fait j'ai l'impression que tous les exemples donnés de l'utilisation de Junit ne sont pas concrets du tout.

Tu as dans une application une méthode qui attend deux entiers et qui renvoie un entier ? Moi jamais

Moi mes méthodes sont très souvent des "void" qui font des insertions en base de donnée ou qui instancient un Objet depuis une sélection dans un table.

Je n'ai pas de méthodes "mathématiques" comme ca

[ego]

Punaise.....
ceux sont des EXEMPLES !!!
Pour le cas des base de données,puisque c'est visiblement cela qui t'intéresse, tu as DBUnit , une extension de JUnit.

cf. http://dbunit.sourceforge.net/

[tipiak]

tu as dis : JUnit : gestion des tests unitaires

je ne serais pas aussi catégorique

c'est un séquenceur d'automatisation de tests unitaires

en gros ils te donne des boites et des méthodes pour faciliter l'automatisation de tes tests
un Runner (intégrable dans l'IDE pour lancer les tests, les notions de suites pour ordonancer tes exécutions)
et des fonctions tels que les assertions et les initialisation et restitution de context (setUp et Teardown)
:
en aucun cas il ne GERE tes tests....

ni meme te dit les tests que tu doit exécuter
(pour cela il faut faire de la génération de graph à partir du code ce qui n'est pas top, car les tests decoulent des requirements et non du code à tester, donc plutot gérérer à partir des spec de ton appli ...)


Sinon donc dans tes cas :
JUNit c'est l'outil qui aide mais il ne va jamais se substituer à ton expertise....

c'est à toi de définir :
- CE que tu souhaite tester (chaques tests et leurs objectifs ...)

- ce qui est necessaire pour le tester...
(une base de donnée qui contien tel et tel truc...)
(que tel serveur soit configuré de telle maniere etc etc ... (l'environnement de test...))

JUnit permet d'automatiser que ce que tu ferais à la main :
par exemple pour tester ta fonction :
ADDUSERINBD
pour chaque test : tu va appeler la fonction ADDUSERinBD
avec des parameters d'entrée selon le UseCase que tu souhaite tester
puis tu va requeter direct la BD pour checker l'OUTPUT de la fonction testée (AddUserinBD) cet output est par exemple un nouvel enregistrement dans la table USER avec les infos qui vont bien ....

Au premier regard de cet exemple tu vas te dire :
mais c'est plus long que de faire le test manuellement ....
la réponse est oui si tu execute le test qu'une seule fois....

JUNIT sequence toutes les actions que tu ferait manuellement c'est juste un BETE script il ne reflechi et n'analyse pas comme le ferait un testeur manuelement...


et c'est la que la GESTION des tests intervient encore
pour définir les critères d'éligibilité d'un test à etre automatisé
(au meme titre que pour des tests manuels, tu les classes par priorité et par criticité)
la un tests possède plus ou moins d'intéret à etre automatisé
(difficulté d'automatisation, fréquence de rejeu, cout d'exécution manuel Vs cout d'exécution Auto), maintenabilité du test auto (Genre si tu test l'ajout d'un champ unique, pour pouvoir rejouer il faut s'assurer que ce champ unique n'existe pas deja dans l'environnement ...)

Bref: L'outillage des tests c'est 10% d'outils et 90 de méthodes et de process.

et l'automatisation necessite plusieurs phases en amont
- une gestion clean des tests
- des objectifs et une strategie de test robuste
- une gestion des environnement de tests
- une strategie d'automatisation (éligibilité des tests à l'automatisation ...)


Désolé pour le pavé
c'est un peu décousu mais l'automatisation de tests est un vaste sujet

et tes questions ou tes problèmes ne semblent pas être très précis (cf les phases en amont par rapport à l'automatisation de tests...)

[elbj]

Bonjour

danyboy85 tu dis que ton appli effectue essentiellement des accès BDD (Insert, Select, ...), JUnit peut t'être très utile...

Exemple :
- Test d'Insertion : tu insères une donnée et tu vérifies par un sélect qu'elle est bien présente dans la base.
- Test de Mise à Jour : tu mets à jour une donnée et tu vérifies par un sélect qu'elle est bien modifiéedans la base.
- Test de Suppression : tu supprimes une donnée précédemment insérée et tu vérifies par un sélect qu'elle est bien présente dans la base.

Voilà, tu as déjà trois exemples de test qui vont parfaitement dans le sens de tes Méthodes de Classe.

Pour ma part j'utilise bcp les tests unitaires et c'est vrai que c'est lourd à mettre en place au début mais c'est un gain de temps inestimable par la suite lorsque tu te rends compte qu'une subtile modification dans les propriétés ou les méthodes d'une classe a des conséquences imprévues sur une autre classe (d'où le contrôle de régression).

Enfin c'est quand même plus rapide de cliquer sur un bouton et attendre la fin des tests (imagine les trois tests ci-dessus pour chacune des tables de ta BDD y compris des tests vérifiant les suppressions en cascade...) que de vérifier sur chaque table si tout fonctionne...

Cordialement

Christophe