Discussion :

[WebPac]

Salut tout le monde, j'espère que je ne me trompe pas de forums, si c'est le cas, ne m'en veuillez pas trop.

Je compte mettre en place DUnit afin de fiabiliser un peu l'application que je développe.

Mais je n'ai aucune expérience sur DUnit et me dis que ça va être super lourd et long de faire des tests sur chaque fonction.

Un exemple, j'ai une fonction qui prend une liste d'objets en paramètres, et va en retourner un parmis tous ces objets.
Pour la tester, il faut créer une liste d'objets, créer des objets, les mettre dans la liste, lancer la fonction et voir si le résultat est l'objet désiré, puis supprimer les objets.

Il faut faire cela, en testant une liste vide, et un éventail de toutes les listes d'objets qu'on peut rencontrer dans l'appli.
Va-t-il falloir à chaque fois créer la liste, les objets et les supprimer ?

J'ai lu que la conception des tests est en général aussi longue que celle du code en lui-même, mais j'ai bien peur que ce ne soit pas le cas.
Sans parler de la non exhaustivité des tests.

Je ne suis pas la pour lancer un troll mais vraiment pour apprendre des xp des autres programmeurs et ne pas tomber dans les pièges possibles grâce à votre aide.

Merci.

[skywaukers]

bonjour,

oui il faut créer les objets et oui il faut les détruire, il y a d'ailleurs les méthodes Setup et Teardown à implémenter dans tes classes de test pour faire cela.
Oui aussi cela prend au moins autant de temps que d'écrire le code utile, donc c'est difficile de statuer sur la rentabilité de la chose. Disons que si tu écris un Hello world tu va perdre ton temps avec DUnit, par contre si tu écris un gros projet qui risque d'évoluer dans le temps alors ça peut vraiment être rentable. Comme tu le dis on ne peut pas être exhaustif, mais le but est de s'en rapprocher le plus raisonnablement possible. Il faut aussi savoir que les classes de tests peuvent aussi évoluer, par exemple quand tu t'aperçoit d'un bogue, que tu le corige, tu peux écrire un test charger de le déceler.
Ce que je dis souvent c'est que les tests unitaires sont un investissement dans le temps, pas sur l'écriture initiale du projet. Ils sont un investissement car ils t'assurent un peu plus la fiabilité de ton appli et surtout, là où manuellement tu prendrais des raccourcis parce que tu as déjà testé 100 fois, que les délais sont court, etc... DUnit lui n'oubliera aucun test et si tu as touché un bout de code qui à une influence ailleurs il te le diras immanquablement, même si c'est sur le code testé déjà 100 fois.

@++
Dany

[WebPac]

Merci pour ta réponse, ça me motive un peu plus de le mettre en place, même si ça n'enlève pas des peurs que ce soit lourd de mettre en place.

Est-ce que tu connais quelquechose pour automatiser les tests d'intégration ?