Discussion :

[LUOAR]

Bonjour,

Je souhaite mettre en place des tests fonctionnels sur une application ntiers en java.
L'utilisation de fitnesse me paraît assez appropriée, mais j'ai peur que ce soit compliqué à maintenir ou à mettre en place.

Si quelqu'un utilise cet outil, je suis preneur de son retour d'expérience.

D'autre part, est ce que c'est un outil adapté pour des tests de non régression?

Merci d'avance.

[geforce]

Je remonte ce post pour avoir des retours d'experience

aussi je vous invite à faire parti du Groupe: Testeur en folie

[thebloodyman]

Salut,

J'ai utilisé fitnesse sur un seul projet durant 6 mois.
Voila mon retour d'XP dessus.
C'est un outil très intéressant pour capturer les besoins métiers d'une façon lisible et claire pour un développeur, un fonctionnel et plus généralement qqn qui a un cerveau.
C'est ce qu'on peut appeler créer des spécifications exécutables.
Pour le développeur, le gros intérêt est l'appropriation du fonctionnel et le transfert de connaissances fonctionnelles faciles entre dév : il suffit d'aller lire les pages du wiki des notions qui nous intéressent pour en savoir plus sur le sujet et même avoir un test programmatique derrière qui valide les informations.
Pour le fonctionnel, l'intérêt c'est de vérifier que les dev répondent bien au besoin métier de l'appli.

Maintenant, l'utilisation de Fitnesse présente quelques inconvénients.
Je vais présenter ceux qui m'ont marqué et les parades associées si il y en a eu.
Nous n'avions à l'époque peut-être pas toutes les connaissances et le temps pour trouver des solutions satisfaisantes à toutes. Si qqn a d'autres solutions aux probs évoqués, meilleures ou non, je suis super preneur

- doublement des tests (un test u classique + un test fitnesse) qui accroit le cout de maintenance ou alors ne pas tester certaines couches unitairement ?
Mais dans ce cas, on galère un peu pour retrouver les tests dans l'ide et on ne peut plus vérifier la non régression unitaire rapidement : il faut à chaque fois lancer Fitnesse.

- doit on mocker ou non les couches sous jacentes au besoin métier testé ?
Le prob c'est qu'on perd les atouts offerts par les classes de bases de test de certains frameworks de tests comme spring-test ou dbunit. On avait par exemple dû finir par créer des méthodes de rincage de base spécialement pour Fitnesse au risque d'avoir une base de test pollué et non consistence.

- cout d'apprentissage des concepts de base : table de décisions, Query, Scripts ... et aussi se familiarisé avec l'interface graphique et la syntaxe. On est plus dans eclipse, on fait du wiki qui mélange nom de classe, méthode et textes statiques.
Pas 36000 solutions pour s'en sortir, il faut en faire régulièrement pour que la logique et la syntaxe rentre. Et surtout avant de commencer à coder le test et le wiki, au début il faut vraiment se poser la question de quels sont les artefacts Fitnesse qui répondront le mieux à mon problème.

- refactor pas intégré dans le wiki. Vous modifier qqch dans le wiki qui est lié à Java, vous devez faire la modification dans le java aussi.

Pour conclure, si vous avez une poignée de besoins fonctionnels à tester (3 ou 4) qui comportent peu de complexité et de variantes et que vous n'avez pas la connaissance du framework, Fitnesse a de grosses chances de vous couter plus qu'il ne vous rapporte.

D'autre part, est ce que c'est un outil adapté pour des tests de non régression?

Oui, la non-régression fonctionnelle je dirais.