quels tests automatiser pour développer en agile des applications J2EE

bonjour,


Voici l'état de mes réflexions et mes questions en gras :

tests unitaires :
couche graphique : rien à faire selon la FAQ Junit si les jsp sont bien faites (you should strive to make all your JSPs too simple to break)
couche métier : tests automatisés avec Junit et une librairie de Mock
couche de persistance/base de données : tests avec Dbunit : on tester la BDD avec la couche de persistance (donc on peut parler de test d'intégration unitaire cf le libre junit in action).

que faire pour la couche naviguation (le contrôleur)? (utiliser cactus?)

tests d'intégration :
je ne vois pas quoi faire comme tests qu'ils soient automatisés ou pas et je n'arrive pas à les dintinguer des tests fonctionnels pour une application web.

tests fonctionnels :
automatisation avec sélénium.
est ce que celà vaut la peine d'automatiser ces tests? . J'ai eu un retour positif d'une société de sous traitance qui a très bien développé une appli web pour nous en utilisant sélénium. Je suis intéressé par tout retour d'expérience concrète.

jusqu'au faut il automatiser les tests pour pouvoir faire un développement agile (ex : XP)? J'ai l'impression qu'il n'y a pas consensus sur le sujet

Cordialement
loïc midy

Salut,

Concernant les tests de controlleur, j'utilise junit aussi pour les tests unitaires.

Si tu as des tests seleniums, effectivement ils testent l'intégration par la meme occasion.

Concernant l'automatisation de tests, quels qu'ils soient, il faut le faire, sinon ça ne sert à rien : les developpeurs oublient de les lancer, et le fait qu'ils soient automatisés fait remonter tout de suite les erreurs (et donc leurs causes). L'automatisation oblige aussi à maintenir les tests. A mes yeux, un test non automatisé ne sert à rien.... A contrario, je ne vois vraiment pas quelles sont les raisons de ne pas le faire...

++
Foucha.

Concernant les test selenium, ici on les utilise pour automatiser le test de tout un série de composant JSF custom. On vérifie que les valeur erronnées donne bien des réponses d'erreur, que le composant réagit bien au requetes etc. Il faut cependant veiller à ce que le test ne soit pas trop précis. Plus tu fais ces tests en aval, plus t'as de risque de voir des changements dans le structure de la page qui n'impactent pas les fonctionnalités de l'application mais posent des problèmes à selenium.

Je suis aussi relativement d'accord pour tester les controleur avec du Junit et une librairie de Mock (Mockito étant ma préférée).

Sinon ma préférence va en effet à favoriser un maximum de tests unitaires puis de tester l'intégration via des tests fonctionnels. Pour la couche graphique je te conseille tellurium plutôt que Selenium. Cette page est très intéressante et je suis assez d'accord, Selenium est très vite limite et vraiment pas agile (pour le refactoring) : http://code.google.com/p/aost/wiki/T...hForWebTesting